Allow re-export of sway modules via pub use.
#3113
Assignees
Labels
compiler
General compiler. Should eventually become more specific as the issue is triaged
enhancement
New feature or request
language feature
Core language features visible to end users
Comments
nfurfaro
added
enhancement
mohammadfawaz
added
the
language feature
|
Just bumping this. |
7 tasks
IGI-111
added a commit
that referenced
this issue
Mar 8, 2024
## Description This PR contains the final bit of refactoring before I start fixing the import problems mentioned in #5498. The semantics of imports has so far been implemented in the `Module` struct, and has assumed that the destination path of an import was relative to `self`. In particular, this allows imports to any submodule of the current module. However, whenever that logic was triggered by the compiler the destination path was always absolute. The only reason this worked was that the logic was only ever triggered on the root module. To reflect this behavior I have therefore moved the import semantics to the `Root` struct, and made it clear in the comments that the paths are assumed to be absolute. This also reflects the fact that once the module structure has been populated with the imported entities we don't actually need the import logic anymore, so it shouldn't be located in the `Module` struct. (Name resolution should obviously stay in the `Module` struct, so that logic has not been moved). I have left a couple of TODOs in the code to remind myself where I need to make changes when I start implementing `pub use` (see #3113 ). ## 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). - [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>
esdrubal
pushed a commit
that referenced
this issue
Aug 13, 2024
## Description Fixes #3113 . Closes #2767 as Won't Fix, since one must use `pub use` to reexport items. This PR Introduce reexports through the use of `pub use`. The implementation now keeps track of the visibility of a `use` statement, and that visibility is in turn taken into account when items are imported from the module where the `use` statement resides. This feature allows `std::prelude` and `core::prelude` to be handled correctly, instead of the special-case handling that we have been using so far. The method `star_import_with_reexports` has therefore been merged with `star_import`, and the `prelude.sw` files have accordingly been changed to use `pub use` instead of `use`. Note that `sway-lib-std/lib.sw` has a spurious import of `core::*`, which has no effect, so I have removed that import. This change also allows us to remove a hacky solution in `lexical_scope.rs`. The hack was introduced because the special-case handling of preludes meant that the preludes would contain multiple copies of the same `std` and `core` items. Now that we no longer need to treat the preludes specially, we can remove the hack. I have gone a little overboard in adding tests, partly because I wanted to make sure I hadn't missed some corner cases, but also because our tests of the import logic has poor code coverage. I have found the following issues that I don't think belongs in this PR, but which need to be handled at some point: - Path resolution is broken. The tests `should_pass/language/reexport/simple_path_access` and `should_fail/language/reexport/simple_path_access` are supposed to test that you can access reexported using a path into the reexporting module, i.e., without importing them using a `use` statement. Both tests are disabled because path resolution is broken. I plan to fix that as part of #5498 . A simlar problem exists in the test `should_pass/language/reexport/reexport_paths` where an item is imported via `std::prelude`. - There is an issue with the import and reexport of enum variants, which is illustrated in `should_pass/language/reexport/reexport_paths_external_lib`. In short, `pub use ext_3_lib::Items3_Variants::U` elevates the name `U` to the top-level namespace in a module, and this makes `U` inaccessible as a variant of `Items3_Variants`. I'm not sure how this is supposed to work, but since it's related to all imports whether they are reexported or not I have left it as a separate issue #6233 . - Aliasing of enum variants (`use lib::Enum::X as MyX`) doesn't work properly. In some cases `MyX` is available in the way you would expect, and in other cases it is not, and sometimes it is available but not recognized as being a variant of `lib::Enum`. The test `should_pass/language/reexport/aliases` has a number of tests of these types of things. #6123 tracks the issue. - Aliased traits are not handled correctly by the dead code analysis. The test `should_pass/language/reexport/aliases` generates warnings about unimplemented traits that are actually implemented, but since they are aliased in imports the DCA doesn't catch them. #6234 tracks the issue. Re. documentation: The whole import system is completely undocumented in the Sway book, and I plan to write up a draft how it works when I'm done fixing (the majority of) the many issue we have there. At the very least I'd like to postpone the documentation efforts until path resolution works correctly, since that is key to how the import system works. ## 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 <joshpbatty@gmail.com> Co-authored-by: João Matos <joao@tritao.eu>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This currently fails with:
The text was updated successfully, but these errors were encountered: