-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
Legal name clash between aliased import and declaration causes problems #5713
Labels
bug
Something isn't working
Comments
jjcnn
changed the title
Name clash between aliased import and declaration
Legal name clash between aliased import and declaration causes problems
Mar 8, 2024
the declared Foo is glable ? |
glable? |
This was referenced Apr 25, 2024
JoshuaBatty
added a commit
that referenced
this issue
May 1, 2024
## Description Fixes #5913 . Name resolution for imports and top-level items in module currently happens at the module level, in part by traversing the submodules of the current module. This PR moves name resolution to the root of the module structure. This refactoring is needed to enable fixes to the following issues: - #5713 : The resolved type declaration must be understood in the context of the declaring module rather than in the context of the importing module, which means that name resolution must happen across the module structure. - #5498 : The modules from which items are imported are currently introduced as submodules to the importing module (in addition to their absolute location in the module hierarchy). To remove those submodules the name resolution algorithm needs access to the full module hierarchy, which it can get by having access to the root of the hierarchy. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: IGI-111 <igi-111@protonmail.com> Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
tritao
pushed a commit
that referenced
this issue
May 2, 2024
## Description Fixes #5912, #5713 . Item imports with aliases `use x::y as z` have so far been represented using two maps: - A synonyms map mapping `y` to the type declaration of `x::y`. - An alias map mapping `z` to `y`. This is confusing, since `y` is not actually bound by this import, and unsurprisingly has lead to a bug because of a name capture (see #5713). This PR eliminates the alias mapping, and changes the synonyms map to map `z` to the type declaration of `x::y`. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The following code causes errors:
The local declaration of
Foo
does not itself cause an error, but when themain
function instantiatesMyFoo
it resolves to the locally declaredFoo
struct and not the imported one.The text was updated successfully, but these errors were encountered: