Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

As a smith I want full support for re-exports across cyclic modules #2338

Open
mor-n4 opened this issue Apr 20, 2022 · 0 comments
Open

As a smith I want full support for re-exports across cyclic modules #2338

mor-n4 opened this issue Apr 20, 2022 · 0 comments

Comments

@mor-n4
Copy link
Contributor

mor-n4 commented Apr 20, 2022

Currently, our scoping assumes that the elements imported into an N4JS resource can be collected in a single go (see invocation of ImportedElementsScopingHelper#getImportedValues() in method N4JSScopeProvider#buildLexicalEnvironmentScope()). However, in case of chains of re-exports across cyclic N4JS files this is not possible and a different approach is required, that collects the elements incrementally across several files.

A preliminary work-around has been implemented in GH-47 by adding two recursion guards in N4JSScopeProvider (search for TODO GH-2338). This will work for many cases, but not all. And overview of supported and unsupported cases can be found in the test file ExportDefinitionInCyclicResourcesTest.xtend.

The goal of this user story is to implement full support for such chains of re-exports across cyclic files. A good starting point could be to disable the two related recursion guards in N4JSScopeProvider(search for TODO GH-2338) and investigate the resulting failures in the above test file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant