idea: detect JS calls at compile time #1367
Description
Recording this idea so it doesn't slip under the radar:
In support of pure finalizers, I'm wondering if it's possible to templetize napi::Environment such that one specialization attaches js-execution-capable finalizers whereas the other attaches pure finalizers. We can use type inference to specialize the right class for a given user-provided finalizer.
That is, if the user's finalizer, after inlining and all, contains no calls to functions that execute JS, then we specialize the environment that attaches pure finalizers, otherwise we specialize the environment that does not. That way, add-on maintainers whose finalizers do not really execute javascript could simply recompile and have their memory leak worries go away without any code changes, once nodejs/node#42651 lands.
The reason I chose napi::Environment as the "probe" which will tell us whether the user's finalizer ends up calling a Node-API that executes JS is that all Node-APIs require an environment, so the type inference will snap to a non-pure napi::Environment if there is even one call to a JS-executing Node-API in the user's code.
We can actually work on this before nodejs/node#42651 lands, but for now we'll attach finalizers the same way whether or not their body calls into JS. Maybe we can use #warning to output compiler messages indicating whether the finalizer would have been pure or not.
Another aspect is this: if there are two napi::Environment classes available and you pass the wrong one to the API that sets up the finalizer, it will fail to compile if you pass a "pure" environment along with a finalizer that does not accept such a "pure" environment.