v8: warn in Template::Set() on improper use

[bnoordhuis]

The next major release will make it a fatal error to use non-primitive
values in function templates and object templates.

Print a warning that includes the C and JS stack trace to tell people to
upgrade their add-ons. The C stack trace is only printed on platforms
that support it (the BSDs, OS X and Linux+glibc.)

Refs: #6216

Speculative - I'd like some input whether other collaborators think it's a good approach. It can get pretty noisy when native code abuses v8::Template::Set() a lot but OTOH, hopefully that means it gets fixed quickly.

CI: https://ci.nodejs.org/job/node-test-pull-request/2319/

[jasnell]

This LGTM but I'm curious how difficult it would be to have native code level warnings like this make use of the JS-level process.emitWarning() mechanism. .. nevermind! sigh, this is in the v8 code lol.

[thefourtheye]

Do we need to leave a to-do here?

[bnoordhuis]

I can add a TODO but what should it say?

[thefourtheye]

Perhaps TODO: Throw Error instead of warning in v7.0?

[bnoordhuis]

Oh, it's not going to throw; newer V8 versions replace it with a CHECK that aborts when it fails.

[thefourtheye]

Oh I see. This is the change which you initially had in #6228, right? This? Then, we may not need a TODO I think. Eventually v8 upgrades will take care of this.

[thefourtheye]

Don't we use dep: as the subsystem? Apart from that LGTM.

[bnoordhuis]

Don't we use dep: as the subsystem?

It's a bit of both. Historically, v8: was used for floating patches; deps: for upgrades. I can change it to deps: warn in v8::Template::Set() on improper use if that's preferred.

[thefourtheye]

Historically, v8: was used for floating patches; deps: for upgrades

Oh, I didn't notice that before. Then we can leave it as it is.

[bnoordhuis]

I forgot, cc @nodejs/v8 @jeisinger.

[ofrobots]

I wonder if it makes sense to add a flag (upstream, and floated here) to silence such runtime deprecation warnings. I do think it is good to be noisy by default on such imminent deprecations, but it would also be nice to be able to silence the warning if the user wishes.

One the problems native modules have had is that they never realize that things have been deprecated for a long time, and discover it when next Node.js major w/ new V8 drop them. If such a runtime deprecation warning flag existed, we could potentially use it for more things.

[bnoordhuis]

I'd be okay with adding a flag but I assume that also calls for some kind of framework inside V8 for logging deprecation notices? Input on what that should look like appreciated; or if you're willing to take that on, I'm happy to step aside.

[jasnell]

@ofrobots ... well, we do already have a flags for handling deprecations and warnings in node of course. Perhaps it would be possible to provide an API for embedders that would allow handling of the runtime deprecations/warnings to be deferred to the embedder? We could then insert our own logic and control the output using the existing --no-deprecation|--trace-deprecation|--throw-deprecation|--no-warnings|--trace-warnings mechanisms.

[jasnell]

Of more immediate concern, however, is whether this particular PR can land as is for v6 or does it need to be tweaked some more?

[bnoordhuis]

If it needs a complete overhaul, then it's not going to be ready for v6.0.0, which would be a shame, IMO.

I can add a flag to deps/v8/src/flag-definitions.h that silences the warning. Suggestions on the name?

[ofrobots]

Given that this is urgent for v6, deciding on the framework before then might not be feasible, I agree.

How about something specific for this case for now; specially if we are not pushing it upstream first? Perhaps [no_]template_set_warning?

[bnoordhuis]

Sounds good, that's more or less what I had in mind. I'll update the PR later today.

[bnoordhuis]

Updated, PTAL. CI: https://ci.nodejs.org/job/node-test-pull-request/2369/

[jasnell]

LGTM if CI is green

[MylesBorins]

@bnoordhuis looks like this is specific to v8 > 5
Set dont-land... please modify if I am incorrect