Editorial: Fix null [[ScriptOrModule]] of function declarations in modules

[devsnek]

There is no context on the stack that contains the current module while modules are setting up their environments, unlike scripts which push their context right before GlobalDeclarationInstantiation. This results in function declarations in modules having null [[ScriptOrModule]] slots. This breaks import.meta and dynamic import inside modules.

[devsnek]

@ljharb suggested adding a [[Module]] slot to module environments and using that in FunctionInitialize.

I'm fine with either approach.

[domenic]

There is no context on the stack that contains the current module while modules are setting up their environments,

Why don't we fix this instead, i.e. make modules and scripts symmetrical?

[ljharb]

My understanding is that for exported declarations, the module isn’t evaluating, so it doesn’t belong on the stack - iow, they can’t be symmetrical because they have a linking phase that scripts lack.

[domenic]

You could still put it on the stack, even if you're not evaluating anything, in order to get the correct results from various algorithms in the spec.

[devsnek]

@domenic the module's context doesn't exist until evaluation

[domenic]

I see. It still seems better to me to move that to linking time. I.e. create the context, and push it onto the stack during linking. (Then pop it off.) Then evaluation can just push/pop the already-created context.

In particular, I find this PR bad because it indicates that there are a lot of mechanisms in the spec that expect a context to be on the stack while setting up functions. We found out that that is not always true, but I'd rather preserve that invariant and restore the assumption, instead of compensating for it.

[allenwb]

@domenic the module's context doesn't exist until evaluation

Yes, and the parts of InitializeEnvironment that correspond to "linking" should not have evaluation-time dependencies because we don't want to preclude doing them with an ahead-of-time linker.

To me, it would seem better to add an scriptOrModule parameter to InstantiateFunctionObject so module InitializeEnvironment can explicitly pass it when instantiating module top-level functions.

[devsnek]

this changeset has been verified with engine262 👍

[jmdyck]

Looks okay to me.