ResolveExport's exportStarSet argument disallows cycles that don't seem problematic

[ajklein]

The exportStarSet passed to ResolveExport is used to cause an error in cases like the following:

A: import {x} from "B";
B: export * from "C";
C: export var y; export {y as x} from "B";

The sequence of ResolveExport calls here is:

1. B.ResolveExport("x", «», «»)
2. C.ResolveExport("x", «{B, "x"}», «B»)
3. B.ResolveExport("y", «{B, "x"}, {C, "x"}», «B»)

where step (3) fails when hitting step 7 of ResolveExport (since B is already in the exportStarSet).

But that would have been perfectly legal without the export *:

A: import {x} from "B";
B: export {x, y} from "C";
C: export var y; export {y as x} from "B";

where the sequence is instead:

1. B.ResolveExport("x", «», «»)
2. C.ResolveExport("x", «{B, "x"}», «»)
3. B.ResolveExport("y", «{B, "x"}, {C, "x"}», «»)
4. C.ResolveExport("y", «{B, "x"}, {C, "x"}, {B, "y"}», «»)

and step (4) results in a a valid resolution.

What's the rationale for the former being an error?

@GeorgNeis who pointed out this oddity, and @allenwb for any history here.

[ajklein]

@caridy @dherman for more modules expertise in case they happen to know what this restriction is for.

[ajklein]

Recapping my understanding of a whiteboard discussion with @dherman: Dave's guess is that the export star set was meant to disallow circularities entirely within a graph of "export *" declarations, and that this failure just falls out of that. It might suffice to make export star detection a separate phase of checking in ModuleDeclarationInstantiation, and to throw away the exportStarSet once that phase is complete.

[ajklein]

@caridy ping? I think you said you were going to take a look at this one.

[caridy]

Yes, will try to have something for next week.