Ambiguous star imports resolved incorrectly #5940
Assignees
Comments
8 tasks
IGI-111
added a commit
that referenced
this issue
May 11, 2024
…ed (#5963) ## Description Fixes #5940. This PR deals with the situation where the same name is imported by multiple star imports, e.g., ``` // a.sw struct X = ... // b.sw struct X = ... // main.sw use a::*; use b::*; ``` So far we have resolved this name clash by letting the latter import shadow the former, which is incorrect. The correct behavior is to allow the import without error, but to report an error if the unqualified name (i.e., `X`) is used (qualified names `a::X` and `b::X` are legal)`. This PR fixes this problem. Note that if `X` is imported multiple times, but each time is bound to the same entity (e.g., because it is imported both through `core:;prelude` and `core::codec`), then this should not cause an error. Note also that there is a problem with the implicit imports from the core and std preludes, which in some cases causes the implementation to think that a name is bound to multiple different entities, even though the entities are actually the same. As a workaround anytime a name is imported from either `std` or `core` when it is already imported from `std` or `core`, the new binding replaces the old one instead of being added as a new binding. Unfortunately this workaround means that it is not currently possible to redefine and use a name that exists in `std` or `core`, e.g., to create a specialized version of `assert_eq` as is done in one of our tests. To use such a redefinition one must use a qualified name for the entity, which seems like an acceptable workaround. (Note that this only applies if the redefined entity is imported using a star import - if imported using an item import (`use a::X;`), then there is no issue). Once #3487 is implemented this workaround should no longer be necessary. ## 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: Joshua Batty <[email protected]> Co-authored-by: IGI-111 <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
a.swb.swmain.swThe text was updated successfully, but these errors were encountered: