'v8::Value::ToNumber': was declared deprecated - c++

I'm trying to access a known object and get one of its properties as a Number
Unfortunately, the following code...
Isolate *isolate = args.GetIsolate();
Local<Object> opts = args[0]->ToObject();
Local<Number> mode = opts->Get(String::NewFromUtf8(isolate, "mode"))->ToNumber();
is giving the following warning:
warning C4996: 'v8::Value::ToNumber': was declared deprecated
....node-gyp\8.5.0\include\node\v8.h(9578): note: see declaration of 'v8::Value::ToNumber'
In the v8.h I noticed the comment on ToNumber: "Use maybe version". I've attempted to convert it to a Maybe but I've not yet been able to get any attempt to compile correctly. What is the correct approach to using Maybe and getting the Number object?

Looks like the "Use maybe version" comment in the v8.h led me in the wrong direction. The deprecate notice seems to apply to the method-overload that is missing the isolate. If you pass the isolate...
->ToNumber(isolate);
it works without warning.

Related

Visual Studio 2017: Ruleset won't execute

I want to define a custom set of rules to be checked at compile time. But it seems not to work.
Example:
I choose one rule directly and I'll get the expected warning.
But when I instead create a custom ruleset containing the exact same rule then I won't get the expected warning.
What could be wrong?
Edit:
void f(std::string& i) {
std::string s = i;
cout << s;
}
int main()
{
std::string s ("abc");
f(s);
}
This gives me the expected warning Warnung C26460 The reference argument 'i' for function 'f' can be marked as const (con.3). in the first case.
Even if I create a custom ruleset including all available rules, I won't get any warnings.
Here you see me selecting the custom ruleset:
Edit: The ruleset action must change one time to enable it.
When I create a new ruleset containing only the const-checks then I will get a .ruleset that does not work and look like this:
In the ruleset editor it looks like this:
When I then change its action from Warning to Error:
Then the .ruleset gets additional lines for each test case:
When I change the action back to warning it looks like this:
Now it is working as expected.
I've been able to reproduce your error with Visual Studio 2017. I don't know exactly what I changed (or if I changed anything at all), but I am able to see the code analysis warning you expect with a custom rule set.
Things I would try:
Double check the Error List window is visible and not hiding somewhere.
Open the rule set file, change the Action to Error and then back to Warning and save it. I wouldn't expect this to be the problem but it's one of the things I did and after which I started seeing the Error List window.

Why I am getting errors from TableGen-generated *.inc files (LLVM)?

I am trying to write an LLVM backend, when I am trying to build it, I get the following error message:
AbcGenRegisterInfo.inc: In static member function 'static const llvm::AbcFrameLowering* llvm::AbcGenRegisterInfo::getFrameLowering(const llvm::MachineFunction&)':
AbcGenRegisterInfo.inc:322:43: error: invalid static_cast from type 'const llvm::TargetFrameLowering*' to type 'const llvm::AbcFrameLowering*'
MF.getSubtarget().getFrameLowering());
^
Here is my AbcRegisterInfo.td (I copied it from here):
class AbcReg<string n> : Register<n> {
let namespace = "Abc";
}
def DUMMY_REG : AbcReg<"R0">;
def RegI64 : RegisterClass<"Abc", [i64], 64, (add DUMMY_REG)>;
I also overrided AbcSubtarget::getFrameLowering() method:
class AbcSubTarget : public AbcGenSubtargetInfo {
AbcFrameLowering *frameLowering;
// more fields and methods
const AbcFrameLowering *getFrameLowering() const override {
return frameLowering;
}
};
but the error message did not change.
I don't understand what to do - I can't just edit AbcGenRegisterInfo.inc, because it will be re-generated every time I will build LLVM, and I don't understand what's wrong in my TableGen files.
I also tried to remove AbcGenRegisterInfo.inc file from my build directory before compiling, but it had no effect.
Does AbcFrameLowering inherit from TargetFrameLowering? It looks like the static cast is complaining because the types are unrelated.
Also make sure the header with the definition of AbcFrameLowering is included before the .inc file is included otherwise the static cast will fail as well.
I have the same exact error, and while I cannot answer your question in full, I believe I can address one part of the issue. You said
I also tried to remove AbcGenRegisterInfo.inc file from my build directory before compiling, but it had no effect.
Unless you mean that AbcGenRegisterInfo.inc was regenerated (and therefore deleting it had no effect), the fact that its absence has no effect should be due to the fact that TableGen has the .inc.tmp file to rely on as a backup. I noticed that when I make with VERBOSE=1, there is a statement that suggests tablegen uses the .tmp files in this way.
Again, not a specific answer to your main question, but just to hopefully help address that issue when trying to debug.

llvm irbuilder call instruction throwing exception on function inlining pass

I'm new to LLVM. I am using the clang c++ API to compile multiple stub files (in c) to IR, and then stick them together using IR builder (after linking them) to eventually run via JIT.
All this works great, unless I add a functionInlining pass to my optimizations, at which point one of these function calls made in IR builder will trigger the following exception when the pass manager is run:
Assertion failed: (New->getType() == getType() && "replaceAllUses of value with new value of different type!"), function replaceAllUsesWith, file /Users/mike/Development/llvm/llvm/lib/IR/Value.cpp, line 356.
This is how I make the call instruction (pretty straight forward):
Function *kernelFunc = mModule->getFunction( (kernel->Name() + StringRef("_") + StringRef(funcName)).str());
if (kernelFunc){
CallInst* newInst = builder.CreateCall(kernelFunc, args);
}
Later the module is optimized:
legacy::PassManager passMan;
PassManagerBuilder Builder;
Builder.OptLevel = 3;
//Builder.Inliner = llvm::createFunctionInliningPass(); //commenting this back in trigger the exception
Builder.populateModulePassManager(passMan);
passMan.run( *mModule ); //exception occurs before this call returns
Any ideas what to look for?
Try running llvm::verifyModule on your module to see if it's correct. You might have an error and have been getting lucky beforehand but it tripped something up in the inliner.
In general assertions check a subset of things that can be wrong with your module but verify checks a lot more.
It could be a bug in LLVM but more than likely it's a bad module, it's easy to happen.
So I finally setup my dev environment so I could inspect the assertion call in the debugger. I turns out the basic block being replaced had a different context set than the one it was being replaced with. going back and making sure IRBuilder was using the same context as the IR parsers solved the problem.

error: enum was not declared in this scope

I added a new value (NULL_IS_NOT_NIL) to an enum in ksql.h
enum
{
PKEY = 0x000001,
NONCOLUMN = 0x000010,
EXPRESSION = 0x000010,
INSERTONLY = 0x000100,
NUMERIC = 0x001000,
NULL_IS_NOT_NIL = 0x010000,
MAXLEN_TABLENAME = 50
};
Unfortunately, this:
Row.SetExtras ("COMMENT2", KROW::NULL_IS_NOT_NIL);
Throws an error.
db.cpp:7727: error: âNULL_IS_NOT_NILâ was not declared in this scope
On the other hand
Row.SetExtras ("COMMENT2", 0x010000);
and
Row.SetExtras (vendor_id, KROW::NUMERIC);
Both work fine and do not throw errors. Right now I can get by by replacing NULL_IS_NOT_NIL with 0x010000, but that is a bad idea. Is there a reason that I am getting this error? Have I missed something obvious?
You've made the changes in the header file, but they are not being reflected in your project. As stated in the comments, the cause was due to it not being pushed to the right folder.
You forgot to give the enum a name: KROW is missing from your code snippet.
On the other hand, if you call it KROW, you will get a redefinition error. So you need to come up with a different solution. (Unless you are editing the system header file directly -- but surely not...)

What has to be Glib::init()'ed in order to use Glib::wrap?

So I'm trying to make use of a GtkSourceView in C++ using GtkSourceViewmm, whose documentation and level of support give me the impression that it hasn't been very carefully looked at in a long time. But I'm always an optimist :)
I'm trying to add a SourceView using some code similar to the following:
Glib::RefPtr<gtksourceview::SourceLanguageManager> source_language_manager = gtksourceview::SourceLanguageManager::create();
Glib::RefPtr<gtksourceview::SourceLanguage> source_language = Glib::wrap(gtk_source_language_manager_guess_language(source_language_manager->gobj(), file, NULL));
Glib::RefPtr<gtksourceview::SourceBuffer> source_buffer = gtksourceview::SourceBuffer::create(source_language);
gtksourceview::SourceView* = m_source_view = new gtksourceview::SourceView(source_buffer);
m_vbox.pack_start(*m_source_view);
Unfortunately, it spits out the warning
(algoviz:4992): glibmm-WARNING **:
Failed to wrap object of type
'GtkSourceLanguage'. Hint: this error
is commonly caused by failing to call
a library init() function.
and when I look at it in a debugger, indeed the second line above (the one with the Glib::wrap()) is returning NULL. I have no idea why this is, but I tried to heed the warning by adding Glib::init() to the begining of the program, but that didn't seem to help at all either.
I've tried Google'ing around, but have been unsuccessful. Does anyone know what Glib wants me to init in order to be able to make that wrap call? Or, even better, does anyone know of any working sample code that uses GtkSourceViewmm (not just regular GtkSourceView)? I haven't been able to find any actual sample code, not even on Google Code Search.
Thanks!
It turns out, perhaps not surprisingly, that what I needed to init was:
gtksourceview::init();
After this, I ran into another problem with one of the parameter to gtksourceview::SourceLanguageManager, but this was caused by a genuine bug which I subsequently reported and was promptly fixed. So everything's working great now!
I use gtkmm. Typically you have to initialize things with something like :
_GTKMain = new Gtk::Main(0, 0, false);
Of course do not forget :
delete _GTKMain;
Check here for details :
http://library.gnome.org/devel/gtkmm/2.19/classGtk_1_1Main.html
(Sorry but the link option does not work ...)