-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Module experiments: Add one more prelude layer for extern crate names passed with --extern
#49789
Conversation
r? @cramertj (rust_highfive has picked a reviewer for you, use r? to override) |
r? @nikomatsakis |
Needs a check-only crater run. |
@bors try |
⌛ Trying commit 554c875651ebc3556fa1864a414b26a28affcf05 with merge 2b913419c4e8baefbf1d4ed00b2623cdccb803fd... |
☀️ Test successful - status-travis |
@petrochenkov nice! |
Ah, I was going to ask why you did it that way -- but of course, that makes sense. |
r=me pending crater results |
@Mark-Simulacrum Are the crater results for this available yet? |
Unfortunately, they aren't; I'd anticipate about 4 more days. This wasn't marked as check-only in the crater spreadsheet so it was started as a normal run :/ |
src/librustc_resolve/lib.rs
Outdated
"access to extern crates through prelude is experimental").emit(); | ||
} | ||
|
||
let crate_id = self.crate_loader.resolve_crate_from_path(ident.name, ident.span); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we use process_path_extern here?
(Just for uniformity with the extern_absolute_paths
code above)
$(RUSTC) shadow-prelude.rs --extern Vec=$(TMPDIR)/libep_vec.rlib | ||
$(RUSTC) feature-gate.rs --extern ep_lib=$(TMPDIR)/libep_lib.rlib 2>&1 | $(CGREP) "access to extern crates through prelude is experimental" | ||
$(RUSTC) relative-only.rs --extern ep_lib=$(TMPDIR)/libep_lib.rlib 2>&1 | $(CGREP) "unresolved import" | ||
$(RUSTC) relative-only.rs --extern ep_lib=$(TMPDIR)/libep_lib.rlib 2>&1 | $(CGREP) "failed to resolve" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why is this using run-make
and not auxiliary? ah, well, I guess we'd have to modify the auxiliary
mechanism to supply --extern
? (doesn't seem that hard... but maybe we leave it for another PR)
@Mark-Simulacrum ping re: crater |
Crater is done, sorry for the delay: http://cargobomb-reports.s3.amazonaws.com/pr-49789/index.html. |
There are a lot of regression, but all regressions I've checked are caused by something that looks like an implementation bug - |
I think the issue is that the |
Actually, can we just not throw feature errors in this case? Ideally the module system would pervasively track when it's resolving user-defined paths vs speculative resolution (in case we wish to lint or throw better messages). But this ideally will be done by creating a better abstraction for paths over I'm going to remove the feature error here ; we have plenty of speculative resolution happening in resolve. A longer term solution would be to implement said abstraction (something that contains an |
Rebased and pushed an update. |
💔 Test failed - status-travis |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Looks like a spurious network failure |
Module experiments: Add one more prelude layer for extern crate names passed with `--extern` Implements one item from https://internals.rust-lang.org/t/the-great-module-adventure-continues/6678/183 When some name is looked up in lexical scope (`name`, i.e. not module-relative scope `some_mod::name` or `::name`), it's searched roughly in the next order: - local variables - items in unnamed blocks - items in the current module - ✨ NEW! ✨ crate names passed with `--extern` ("extern prelude") - standard library prelude (`Vec`, `drop`) - language prelude (built-in types like `u8`, `str`, etc) The last two layers contain a limited set of names controlled by us and not arbitrary user-defined names like upper layers. We want to be able to add new names into these two layers without breaking user code, so "extern prelude" names have higher priority than std prelude and built-in types. This is a one-time breaking change, that's why it would be nice to run this through crater. Practical impact is expected to be minimal though due to stylistic reasons (there are not many `Uppercase` crates) and due to the way how primitive types are resolved (#32131).
☀️ Test successful - status-appveyor, status-travis |
Woohoo! Thanks @petrochenkov and @Manishearth for seeing this through! |
Is this in the latest nightly? If so, it doesn't seem to be working for me (this commit doesn't build): I see:
|
@nikomatsakis |
Hmm, it seems that the commits appear in the git log, so maybe I'm doing something wrong? |
Ah, I see, duh. Thanks! |
idiom lints for removing `extern crate` Based off of #49789 This contains two lints: - One that suggests replacing pub extern crates with pub use, and removing non-pub extern crates entirely - One that suggests rewriting `use modulename::...::cratename::foo` as `cratename::foo` The latter is a bit tricky to emit suggestions for; for one this involves splicing spans (never a good idea), and it also won't be able to correctly handle `use module::{cratename, foo}` and use-trees. I'm not sure how to proceed here. Currently it doesn't suggest anything at all. Perhaps we can go the other way and suggest removal of all extern crates _except_ those used through modules (stash node ids somewhere) and suggest replacing those with `<visibility> use`? r? @nikomatsakis fixes #48719
idiom lints for removing `extern crate` Based off of #49789 This contains two lints: - One that suggests replacing pub extern crates with pub use, and removing non-pub extern crates entirely - One that suggests rewriting `use modulename::...::cratename::foo` as `cratename::foo` The latter is a bit tricky to emit suggestions for; for one this involves splicing spans (never a good idea), and it also won't be able to correctly handle `use module::{cratename, foo}` and use-trees. I'm not sure how to proceed here. Currently it doesn't suggest anything at all. Perhaps we can go the other way and suggest removal of all extern crates _except_ those used through modules (stash node ids somewhere) and suggest replacing those with `<visibility> use`? r? @nikomatsakis fixes #48719
Implements one item from https://internals.rust-lang.org/t/the-great-module-adventure-continues/6678/183
When some name is looked up in lexical scope (
name
, i.e. not module-relative scopesome_mod::name
or::name
), it's searched roughly in the next order:--extern
("extern prelude")Vec
,drop
)u8
,str
, etc)The last two layers contain a limited set of names controlled by us and not arbitrary user-defined names like upper layers. We want to be able to add new names into these two layers without breaking user code, so "extern prelude" names have higher priority than std prelude and built-in types.
This is a one-time breaking change, that's why it would be nice to run this through crater.
Practical impact is expected to be minimal though due to stylistic reasons (there are not many
Uppercase
crates) and due to the way how primitive types are resolved (#32131).