Throw for uninstantiated dynamic module access

[guybedford]

This is an alternative to #3, where instead of altering execution to ensure that checking export names on dynamic modules isn't possible before they have been instantiated, we always throw in this scenario.

To recap, the problem case as in #3 is:

a.mjs

import './b.mjs';
export * from 'dynamic';
console.log('a exec');

b.mjs

import * as a from './a.mjs';
console.log('b exec');
console.log(a);

Where dynamic is a dynamic module and if importing a.mjs first, we will find that b.mjs is executed before dynamic is executed, so that we will be logging the namespace exports of the dynamic module before it is executed.

The approach taken in this PR is using the fact that instantiate order exactly matches execution order, such that we can catch this problem during instantiation.

The check is that GetExportedNames is called on the dynamic module before it has instantiated, so we can do a null return here to indicate an error to then throw in the Runtime Semantics of GetModuleNamespace.

In addition, this fixes the fact that this was previously a bug in the instantiation process as well.

This comprehensively defends against invalid access to the dynamic module, so I would like to merge this soon and close out #3.

Would value help on the review of the approach, and if this works ok in the spec format. The completion handling may need a second look.

//cc @bmeck @caridy

[guybedford]

@GeorgNeis this implements the approach we discussed to deal with the reference issues in instantiate and execute. Would be interested to hear your thoughts on the approach.

[guybedford]

I've merged this in, along with closing #3.

[guybedford]

I just wanted to summarize the logic here again for reference as I was going through it again today:

If you have a reference to a dynamic module namespace or a namespace which reflects export * exports off of a dynamic module namespace then you must have that dynamic module as a dependency. The problematic case is where that dynamic module in question is unexecuted, and this only happens when there is a "circular leaf case" (as in the example here). We can comprehensively detect these circular leaf cases since instantiation order follows execution order, and the PR here ensures we throw whenever it happens in a dynamic module graph.