CompileFunctionInContext is deprecated

[targos]

[850/3712] CXX obj/deps/icu-small/source/common/icutools.servlkf.o
../../src/node_contextify.cc:1178:51: warning: 'CompileFunctionInContext' is deprecated: Use CompileFunction [-Wdeprecated-declarations]
  MaybeLocal<Function> maybe_fn = ScriptCompiler::CompileFunctionInContext(
                                                  ^
../../deps/v8/include/v8-script.h:691:3: note: 'CompileFunctionInContext' has been explicitly marked deprecated here
[850/3712] CXX obj/deps/icu-small/source/common/icutools.stringpiece.o  V8_DEPRECATE_SOON("Use CompileFunction")
  ^
../../deps/v8/include/v8config.h:462:39: note: expanded from macro 'V8_DEPRECATE_SOON'
# define V8_DEPRECATE_SOON(message) [[deprecated(message)]]
                                      ^
1 warning generated.
[1133/2485] CXX obj/src/libnode.node_native_module.o
../../src/node_native_module.cc:278:23: warning: 'CompileFunctionInContext' is deprecated: Use CompileFunction [-Wdeprecated-declarations]
      ScriptCompiler::CompileFunctionInContext(context,
                      ^
../../deps/v8/include/v8-script.h:691:3: note: 'CompileFunctionInContext' has been explicitly marked deprecated here
  V8_DEPRECATE_SOON("Use CompileFunction")
  ^

See https://source.chromium.org/chromium/_/chromium/v8/v8.git/+/78387ca75dc95e39118805fa72e52aea12a37a66

It's not trivial to migrate, because script_or_module_out isn't exposed anymore but we use it.

[devsnek]

Looking at the diff it seems like maybe we can do CompileFunction()->GetUnboundScript()->BindToCurrentContext()? nvm i see the issue. this is quite annoying :(

[targos]

@nodejs/v8 do you have any suggestions on how we could migrate to the new API?

[hashseed]

@camillobruni

[camillobruni]

This is the first part of a multistage fix to get around the implementation issues with host-defined options :(.

• CompileFunctionInContext works for now for now (minus the deprecation):
  • It creates temporary ScriptOrModule objects (slow, but backwards compatible)
  • It references the temporary ScriptOrModule objects from the Script if the v8_scriptormodule_legacy_lifetime is set to be backwards compatible with node

Pending Work:

• The main fix is ready for V8 but pending on nodejs fixes for modules
• Host-defined options will be allowed to be an arbitrary embedder-defined object (increased risk of leaks, but greatly improved ergonomics). This should fix node's current hack to keep module-metadata alive via ScriptOrModule lifetimes.

[camillobruni]

For the time being I could un-deprecate CompileFunctionInContext (since I've updated V8 + blink already). WDYT?

[devsnek]

Host-defined options will be allowed to be an arbitrary embedder-defined object 

I think as long as this is out before CompileFunctionInContext is removed we can keep using it deprecated for now.

It sounds like we should enable v8_scriptormodule_legacy_lifetime though.

[camillobruni]

I plan to only remove CompileFunctionInContext once the complete API migration is complete.

[targos]

@camillobruni I think this is the source of the errors in #213.

I'm wondering why your Node.js integration tests don't catch them.

[camillobruni]

So far we don't have a bot that fails with deprecation warnings (based on your comment we're likely adding a compile-only bot with deprecation warnings on).

In general we don't really have the capacity to fix node full time, but in this case communication might have not been ideal. We try to limit API churn for as much as possible, but there is quite some work ahead to make modules work properly (see https://crbug.com/1244145), so I apologise in advance for the noise this will generate.

[targos]

Sorry, I missed @devsnek's comment. The solution to #213 was to enable v8_scriptormodule_legacy_lifetime.