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

Legal name clash between aliased import and declaration causes problems #5713

Open
jjcnn opened this issue Mar 8, 2024 · 2 comments
Open
Assignees
Labels
bug Something isn't working

Comments

@jjcnn
Copy link
Contributor

jjcnn commented Mar 8, 2024

The following code causes errors:

use foo::Foo as MyFoo;

struct Foo {
    A: u64,
}

fn main() -> u64 {
    let foo = MyFoo {
        foo: 42,
    };
    foo.foo
}

The local declaration of Foo does not itself cause an error, but when the main function instantiates MyFoo it resolves to the locally declared Foo struct and not the imported one.

@jjcnn jjcnn added the bug Something isn't working label Mar 8, 2024
@jjcnn jjcnn changed the title Name clash between aliased import and declaration Legal name clash between aliased import and declaration causes problems Mar 8, 2024
@jjcnn jjcnn self-assigned this Mar 8, 2024
@shexinyi9527
Copy link

the declared Foo is glable ?

@jjcnn
Copy link
Contributor Author

jjcnn commented Mar 12, 2024

the declared Foo is glable ?

glable?

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
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants