Uh oh!
There was an error while loading. Please reload this page.
resolve: Refactor how the prelude is handled - #32167
Conversation
jseyfried
commented
Mar 10, 2016
petrochenkov
commented
Mar 10, 2016
Do you plan to change the prelude injection code in libsyntax? I'd suppose that with these changes prelude can be injected once into the crate root. (Is it ever useful to have different preludes used in different modules?) |
jseyfried
commented
Mar 10, 2016
I wasn't planning on refactoring the prelude injection code in If we decide to stabilize something allowing different preludes for different modules, we could always make the the field |
bors
commented
Mar 10, 2016
☔ The latest upstream changes (presumably #32097) made this pull request unmergeable. Please resolve the merge conflicts. |
ccd6049 to
43ff7c3Comparenikomatsakis
commented
Mar 11, 2016
Can you elaborate a bit more on the larger picture you have in mind for this change? Sorry, there's been a lot in flight lately -- especially around resolve, huzzah! -- and I feel like I'm losing track. |
jseyfried
commented
Mar 11, 2016
Sure -- this is a pure refactoring. The primary motivation is to reflect the interpretation of the prelude we discussed in #31908 and to simplify the core import resolution algorithm by removing The last commit lays the groundwork for item-like private imports by making a distinction between resolving in a lexical scope (i.e. allowing private imports and the prelude) and allowing private imports but not the prelude. Right now, we never need to allow private imports and not the prelude, but eventually ... structBar;mod foo {useBar;use foo::BarasBaz;// ... we will want this to resolve (a private import),use foo::Ok;// but not this (a name from the prelude).} |
| // module's exports ahead of time. | ||
| module_.inc_glob_count(is_public) | ||
| } | ||
| _ => {} |
There was a problem hiding this comment.
I would suggest avoiding _ but rather keeping the match exhaustive, with a comment explaining why this case requires no action. This has two advantages:
- Helps the reader know why the prelude case is different.
- Gives you errors if you add new enum variants.
nikomatsakis
commented
Mar 25, 2016
Looks good, r=me modulo the match. |
exclude the prelude from `resolve_name(.., allow_private_imports = true)`.
43ff7c3 to
54cd4d1Comparejseyfried
commented
Mar 25, 2016
@bors r=nikomatsakis |
bors
commented
Mar 25, 2016
📌 Commit 54cd4d1 has been approved by |
bors
commented
Mar 25, 2016
resolve: Refactor how the prelude is handled This PR refactors how the prelude is handled in `resolve`. Instead of importing names from the prelude into each module's `resolutions`, this PR adds a new field `prelude: RefCell<Option<Module>>` to `ModuleS` that is set during import resolution but used only when resolving in a lexical scope (i.e. the scope of an initial segment of a relative path). r? @nikomatsakis
This PR refactors how the prelude is handled in
resolve.Instead of importing names from the prelude into each module's
resolutions, this PR adds a new fieldprelude: RefCell<Option<Module>>toModuleSthat is set during import resolution but used only when resolving in a lexical scope (i.e. the scope of an initial segment of a relative path).r? @nikomatsakis