Step 4.a.i is:
Assert: module provides the leaf binding for this export.
It's not clear to me if "leaf binding" is supposed to mean something like "direct binding". If so, that seems too strong, as the exported binding could itself have been imported (see example on es-discuss: https://esdiscuss.org/topic/re-exporting-imports-and-createimportbinding-assertions)
This same usage of "leaf binding" (and the same issue) occurs in GetExportedNames, step 5.a.
(In reply to Adam Klein from comment #0)
> Step 4.a.i is:
>
> Assert: module provides the leaf binding for this export.
>
> It's not clear to me if "leaf binding" is supposed to mean something like
> "direct binding". If so, that seems too strong, as the exported binding
> could itself have been imported (see example on es-discuss:
> https://esdiscuss.org/topic/re-exporting-imports-and-createimportbinding-
> assertions)
Nope. Note that the step 4 loops is over the [[LocalExportEntries]] which Table 38 defines as corresponding to actual declarations that occur within the module. Reexported imports show up in the [[IndirectExportEntries]] list.
I changed the two occurence of "leaf" to "direct". Does that help?
Ah, interesting, this is why I sent a mail to es-discuss first, as I thought I might be missing something. Here's my example from the mailing list:
module 'a':
import { x } from 'b';
module 'b':
import { x } from 'c'; export { x };
module 'c':
export let x = 42;
Can you explain how the "export { x };" declaration in module 'b' results in an ExportEntry record in b's [[IndirectExportEntries]]?
My reading of the static semantics suggests that the generated ExportEntry is:
{ [[ExportName]]: 'x', [[ModuleRequest]]: null, [[ImportName]]: null, [[LocalName]]: 'x' }
and step 10.a of ParseModule requires an entry with a null [[ModuleRequest] slot to be placed in [[LocalExportEntries]].
(In reply to Adam Klein from comment #3)
> Ah, interesting, this is why I sent a mail to es-discuss first, as I thought
> I might be missing something. Here's my example from the mailing list:
>
...
>
> { [[ExportName]]: 'x', [[ModuleRequest]]: null, [[ImportName]]: null,
> [[LocalName]]: 'x' }
>
> and step 10.a of ParseModule requires an entry with a null [[ModuleRequest]
> slot to be placed in [[LocalExportEntries]].
Ah, good catch!! (It's scary that nobody else has caught that yet)
I'm fixing Step 10 of ParseModule so it places such export entries (with the import info) into [[IndirectExportEntries]]
In Rev37