Skip to content
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

Merged
merged 1 commit into from
May 1, 2018

Conversation

petrochenkov
Copy link
Contributor

@petrochenkov petrochenkov commented Apr 8, 2018

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).

@rust-highfive
Copy link
Collaborator

r? @cramertj

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 8, 2018
@petrochenkov
Copy link
Contributor Author

petrochenkov commented Apr 8, 2018

r? @nikomatsakis
cc @aturon

@petrochenkov
Copy link
Contributor Author

Needs a check-only crater run.

@petrochenkov petrochenkov added the S-waiting-on-crater Status: Waiting on a crater run to be completed. label Apr 8, 2018
@Mark-Simulacrum
Copy link
Member

@bors try

@bors
Copy link
Contributor

bors commented Apr 8, 2018

⌛ Trying commit 554c875651ebc3556fa1864a414b26a28affcf05 with merge 2b913419c4e8baefbf1d4ed00b2623cdccb803fd...

@bors
Copy link
Contributor

bors commented Apr 8, 2018

☀️ Test successful - status-travis
State: approved= try=True

@nikomatsakis
Copy link
Contributor

@petrochenkov nice!

@nikomatsakis
Copy link
Contributor

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.

Ah, I was going to ask why you did it that way -- but of course, that makes sense.

@nikomatsakis
Copy link
Contributor

r=me pending crater results

@pietroalbini pietroalbini removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 12, 2018
@cramertj
Copy link
Member

@Mark-Simulacrum Are the crater results for this available yet?

@Mark-Simulacrum
Copy link
Member

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 :/

"access to extern crates through prelude is experimental").emit();
}

let crate_id = self.crate_loader.resolve_crate_from_path(ident.name, ident.span);
Copy link
Member

@Manishearth Manishearth Apr 20, 2018

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"
Copy link
Contributor

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)

@nikomatsakis
Copy link
Contributor

@Mark-Simulacrum ping re: crater

@Mark-Simulacrum
Copy link
Member

Crater is done, sorry for the delay: http://cargobomb-reports.s3.amazonaws.com/pr-49789/index.html.

@petrochenkov
Copy link
Contributor Author

There are a lot of regression, but all regressions I've checked are caused by something that looks like an implementation bug - iovec in libc::iovec is interpreted as a crate iovec.
Why on earth resolve_ident_in_lexical_scope is even called for something that is not in lexical scope?
I need to investigate.

@TimNN TimNN added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-crater Status: Waiting on a crater run to be completed. labels Apr 24, 2018
@Manishearth
Copy link
Member

I think the issue is that the unused_qualifications lint is barging in and trying to resolve this against the root, hitting the feature gate. We should probably silently return None when stuff is being resolved speculatively.

@Manishearth
Copy link
Member

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 &[Ident]. Due to #50100 we already track this in part with the node_id argument to resolve_path but that isn't perfect.

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 &[Ident] and Option<NodeId>) -- this can be mentored.

@Manishearth
Copy link
Member

Rebased and pushed an update.

@bors
Copy link
Contributor

bors commented May 1, 2018

💔 Test failed - status-travis

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels May 1, 2018
@rust-highfive

This comment has been minimized.

@rust-highfive

This comment has been minimized.

@petrochenkov
Copy link
Contributor Author

Looks like a spurious network failure
@bors retry

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 1, 2018
@bors
Copy link
Contributor

bors commented May 1, 2018

⌛ Testing commit c1492fe with merge 4d7bbdd...

bors added a commit that referenced this pull request May 1, 2018
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).
@bors
Copy link
Contributor

bors commented May 1, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: nikomatsakis
Pushing 4d7bbdd to master...

@aturon
Copy link
Member

aturon commented May 1, 2018

Woohoo! Thanks @petrochenkov and @Manishearth for seeing this through!

@nikomatsakis
Copy link
Contributor

Is this in the latest nightly? If so, it doesn't seem to be working for me (this commit doesn't build):

nikomatsakis/polonius@fd3e48f

I see:

-*- mode: compilation; default-directory: "~/versioned/borrow-check/" -*-
Compilation started at Thu May  3 06:43:32

cargo test
   Compiling assert_cli v0.5.4
   Compiling borrow-check v0.1.0 (file:///home/nmatsakis/versioned/borrow-check)
error[E0432]: unresolved import `abomonation_derive`
 --> src/facts.rs:1:5
  |
1 | use abomonation_derive::Abomonation;
  |     ^^^^^^^^^^^^^^^^^^ Maybe a missing `extern crate abomonation_derive;`?

error[E0432]: unresolved import `fxhash`
  --> src/output/mod.rs:14:5
   |
14 | use fxhash::FxHashMap;
   |     ^^^^^^ Maybe a missing `extern crate fxhash;`?

error[E0432]: unresolved import `fxhash`
 --> src/output/dump.rs:3:5
  |
3 | use fxhash::FxHashMap;
  |     ^^^^^^ Maybe a missing `extern crate fxhash;`?

error[E0433]: failed to resolve. Maybe a missing `extern crate differential_dataflow;`?
  --> src/output/timely.rs:15:5
   |
15 | use differential_dataflow::collection::Collection;
   |     ^^^^^^^^^^^^^^^^^^^^^ Maybe a missing `extern crate differential_dataflow;`?

...

@petrochenkov
Copy link
Contributor Author

@nikomatsakis
Prelude doesn't affect resolution for absolute paths (including imports).
Resolve-the-first-segment-as-extern-crate for absolute paths is enabled by feature(extern_absolute_paths).

@nikomatsakis
Copy link
Contributor

Hmm, it seems that the commits appear in the git log, so maybe I'm doing something wrong?

@nikomatsakis
Copy link
Contributor

Ah, I see, duh. Thanks!

bors added a commit that referenced this pull request May 7, 2018
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
bors added a commit that referenced this pull request May 8, 2018
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
@petrochenkov petrochenkov deleted the prelext branch June 5, 2019 16:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants