8.1.1.5.5 CreateImportBinding (N, M, N2)
Step 4:
> Assert: When M.[[Environment]] is instantiated it will have a direct binding for N2.
I think this assertion actually needs to test that the module record M was successfully instantiated, i.e. its ModuleDeclarationInstantiation concrete method has been invoked and successfully completed (cf. 15.2.1.15.5 ModuleEvaluation step 2).
Also, as I mentioned in a thread to es-discuss (https://esdiscuss.org/topic/re-exporting-imports-and-createimportbinding-assertions), this assertion's claim about the binding of N2 seems too strong: it needs to have a binding, but it may be an indirect binding if it is itself an import binding.
(In reply to André Bargull from comment #0)
> 8.1.1.5.5 CreateImportBinding (N, M, N2)
>
> Step 4:
> > Assert: When M.[[Environment]] is instantiated it will have a direct binding for N2.
>
> I think this assertion actually needs to test that the module record M was
> successfully instantiated, i.e. its ModuleDeclarationInstantiation concrete
> method has been invoked and successfully completed (cf. 15.2.1.15.5
> ModuleEvaluation step 2).
I don't thing that needs to be true at the time the binding is created. If the binding is every used (via GetBindingValue) and M has not been fully instantiated then GetBindingValue with throw because M.[[Environbment]] will be undefined.
All the assertion is saying is that the source code for M must have a local export for the referenced name. It's essentially an assertion about the linkability of the two modules rather than about actual initializaiton
(In reply to Adam Klein from comment #1)
> Also, as I mentioned in a thread to es-discuss
> (https://esdiscuss.org/topic/re-exporting-imports-and-createimportbinding-
> assertions), this assertion's claim about the binding of N2 seems too
> strong: it needs to have a binding, but it may be an indirect binding if it
> is itself an import binding.
No the only place CreateImportBinding is called (in ModuleDeclarationInstantiation) M and N2 are supplied by a preceding call to ResolveExport where the /resolution/ has already been determine to be neither unresolved or ambiguous. Because ResolveExport in such cases never resolves to another indirect binding. Instead it always resolved to the "leaf" definition (ie, a module binding that is not an indirect binding).
With the fixes made in rev37 WRT indirect bindings and export records should address the concern in comment #1