Editorial: Handle non-direct binding cases in ResolveExports

[kimjg1119]

In step 6.a.iv.3 of ResolveExport, the case where e.[[ImportName]] is ALL, indicating that the module does not provide a direct binding, is addressed. I’m uncertain but curious whether we should also handle other cases such as ALL-BUT-DEFAULT and null in this context.

c.f. This is problematic because the recursive call in step 6.a.iv.4 requires exportName to be a string. Therefore, the remaining cases should be explicitly handled in some way.

[nicolo-ribaudo]

ALL-BUT-DEFAULT is only used for export * from "foo", which has [[ExportName]] set to null and thus can never happen here. I would prefer if we added an assertion after step 6.a.i saying that [[ImportName]] is not ALL-BUT-DEFAULT.

It might be helpful to look at Table 58: the only cases that can happen in this code path are those where the first two columns are not null.

[kimjg1119]

Thank you for clarifying! I replaced it with an assertion instead.

[bakkot]

Instead of ruling out two of the four possible states here, and then switching between the remaining two later, I would add another assert in the "else" case below (after the existing "imports a specific binding" assert):

                  1. Assert: _e_.[[ImportName]] is a String.

That seems clearer.