Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upResolveExport's exportStarSet argument disallows cycles that don't seem problematic #708
Comments
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
ajklein
Dec 1, 2016
Contributor
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.
|
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. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
ajklein
Jan 17, 2017
Contributor
@caridy ping? I think you said you were going to take a look at this one.
|
@caridy ping? I think you said you were going to take a look at this one. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
Yes, will try to have something for next week. |
ajklein commentedOct 7, 2016
The
exportStarSetpassed toResolveExportis 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:
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:
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.