resolve: Refactor how the prelude is handled #32167
Conversation
|
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?) |
|
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 |
|
☔ The latest upstream changes (presumably #32097) made this pull request unmergeable. Please resolve the merge conflicts. |
jseyfried
force-pushed
the
refactor_prelude
branch
from
ccd6049 to
43ff7c3
Compare
|
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. |
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 ... struct Bar;
mod foo {
use Bar;
use foo::Bar as Baz; // ... we will want this to resolve (a private import),
use foo::Ok; // but not this (a name from the prelude).
} |
| // Set the glob flag. This tells us that we don't know the | ||
| // 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.
|
Looks good, r=me modulo the match. |
exclude the prelude from `resolve_name(.., allow_private_imports = true)`.
jseyfried
force-pushed
the
refactor_prelude
branch
from
43ff7c3 to
54cd4d1
Compare
|
@bors r=nikomatsakis |
|
📌 Commit 54cd4d1 has been approved by |
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