Re-exporting imports and CreateImportBinding assertions

# Adam Klein (10 years ago)

I have a question about CreateImportBinding(N, M, N2) (where N is the name to create in the importing module, and M is a module which exports N2).

Step 4 of people.mozilla.org/~jorendorff/es6-draft.html#sec-createimportbinding is the following assertion

"Assert: When M.[[Environment]] is instantiated it will have a direct binding for N2."

What about the case were M is simply re-exporting an import? Consider:

module 'a':

import { x } from 'b';
module 'b':

import { x } from 'c';
export { x };
module 'c':

export let x = 42;

In this case, when running CreateImportBinding(x, 'b', x) in module 'a', the assertion fails, as x in 'b' is an "immutable indirect binding" (itself created by CreateImportBinding).

Is there a need for this assert I'm missing? I don't think skipping over this assert, or removing "direct" from its wording, will cause any problems. Also, the term "direct binding" is not defined anywhere that I can find, except as the negation of the "indirect" binding created by CreateImportBinding.

Note that there's a similar issue in ResolveExport: step 4.a.i of people.mozilla.org/~jorendorff/es6-draft.html#sec-resolveexport asserts that resolved exports found in [[LocalExportEntries]] are "leaf bindings" (another term that goes undefined), where by the usual CS definition of "leaf" the assertion would be false for x in 'b' (when resolved from 'a').

# Adam Klein (10 years ago)

I've added this to a few bugs on the bug-tracker:

ecmascript#4184 (CreateImportBinding) ecmascript#4244 (GetExportedNames and ResolveExport)

# Adam Klein (10 years ago)

And to close the loop: rev37 makes clear that ResolveExport() will follow re-exported import bindings to discover the module in which they originated. This makes all the assertions correct. In my example, it means that the CreateImportBinding call in 'a' is:

CreateImportBinding(x, 'c', x)

Thanks to Allen for the swift turnaround of these changes.