rustc_resolve: allow only core, std, meta and --extern in Rust 2018 paths. by eddyb · Pull Request #54116 · rust-lang/rust

eddyb · 2018-09-11T01:19:02Z

Rust 2018 imports can no longer refer to crates not in "extern prelude"
- ::foo won't load a crate named foo unless foo is in the "extern prelude"
- extern crate foo;, however, remains unchanged (can load arbitrary crates)
--extern crate_name is added (note the lack of =path) as an unstable option
- adds crate_name to the "extern prelude" (see above)
- crate is searched in sysroot & library paths, just like extern crate crate_name.
- Cargo support will be added later
core, std and ~~proc_macro~~meta are always available in the extern prelude
- warning for interaction with no_std / no_core will be added later
- EDIT: proc_macro was replaced by meta, see std-using paths work just fine in 2018 edition #![no_std] #53166 (comment)
  - note that there is no crate named meta being added, so use meta::...; will fail, we're only whitelisting it so we can start producing uniform_paths compatibility errors

Fixes#54006 (as the example now requires --extern alloc, which is unstable).
Fixes#54253 (hit during fixing RLS).

r? @petrochenkov cc @aturon @alexcrichton @Centril @joshtriplett

petrochenkov · 2018-09-11T09:49:19Z

I'm still unhappy about forever hardcoding proc_macro, which can't be off-loaded to the library prelude unlike core/std, in the compiler, but at least it's already hardcoded for other reasons.

bors · 2018-09-11T09:49:20Z

📌 Commit 0bde629b8df4412b210fed0ef4b8b81592a35278 has been approved by petrochenkov

aturon · 2018-09-11T16:32:33Z

LGTM

@petrochenkov

rustc_resolve: allow only core, std, meta and --extern in Rust 2018 paths. As per #53166 (comment): * Rust 2018 imports can no longer refer to crates not in "extern prelude" * `::foo` won't load a crate named `foo` unless `foo` is in the "extern prelude" * `extern crate foo;`, however, remains unchanged (can load arbitrary crates) * `--extern crate_name` is added (note the lack of `=path`) as an unstable option * adds `crate_name` to the "extern prelude" (see above) * crate is searched in sysroot & library paths, just like `extern crate crate_name`. * `Cargo` support will be added later * `core`, `std` and ~~`proc_macro`~~ `meta` are *always* available in the extern prelude * warning for interaction with `no_std` / `no_core` will be added later * **EDIT**: `proc_macro` was replaced by `meta`, see #53166 (comment) * note that there is no crate named `meta` being added, so `use meta::...;` will fail, we're only whitelisting it so we can start producing `uniform_paths` compatibility errors Fixes#54006 (as the example now requires `--extern alloc`, which is unstable). Fixes#54253 (hit during fixing RLS). r? @petrochenkov cc @aturon @alexcrichton @Centril @joshtriplett

bors · 2018-09-15T22:14:21Z

☀️ Test successful - status-appveyor, status-travis
Approved by: petrochenkov
Pushing e4ba1d4 to master...

rust-highfive · 2018-09-15T22:15:37Z

📣 Toolstate changed by #54116!

Tested on commit e4ba1d4.
Direct link to PR: #54116

🎉 clippy-driver on windows: test-fail → test-pass.
🎉 clippy-driver on linux: test-fail → test-pass.

Tested on commit rust-lang/rust@e4ba1d4. Direct link to PR: <rust-lang/rust#54116> 🎉 clippy-driver on windows: test-fail → test-pass. 🎉 clippy-driver on linux: test-fail → test-pass.

eddyb · 2018-09-15T22:27:35Z

cc @rust-lang/release I believe this was the last blocker for RC.

Nemo157 · 2018-09-18T07:58:38Z

This change (I assume) affects benchmarks as use test::Bencher; no longer finds the test crate. Presumable any test using test::black_box is similarly affected. Should the test crate also be included for test targets, or should these still use extern crate test;? (I’m not sure which tracking issue actually covers the extern prelude stuff, so I’ll just leave this here).

eddyb · 2018-09-18T08:25:56Z

@Nemo157extern crate until we get something else like [dependencies] test = "builtin" into Cargo.

Details: rust-lang/rust#54116

Add option to run all tests, again This is a repeat of #53527, which had to be reverted to land #54116. It will break clippy until `compiletest-rs` can be updated and I believe we're closing on a new release date, so this may need to be delayed again until after 1.30 is out (?) Closes#50363 again

Stabilize --extern flag without a path. This stabilizes the `--extern` flag without a path, implemented in rust-lang#54116. This flag is used to add a crate that may be found in the search path to the extern prelude. The intent of stabilizing this now is to change Cargo to emit this flag for `proc_macro` when building a proc-macro crate. This will allow the ability to elide `extern crate proc_macro;` for proc-macros, one of the few places where it is still necessary. It is intended that Cargo may also use this flag for other cases in the future as part of the [std-aware work](https://github.com/rust-lang/wg-cargo-std-aware/). There will likely be some kind of syntax where users may declare dependencies on other crates (such as `alloc`), and Cargo will use this flag so that they may be used like any other crate. At this time there are no short-term plans to use it for anything other than proc-macro. This will not help for non-proc-macro crates that use `proc_macro`, which I believe is not too common? An alternate approach for proc-macro is to use the `meta` crate, but from my inquiries there doesn't appear to be anyone interested in pushing that forward. The `meta` crate also doesn't help with things like `alloc` or `test`. cc rust-lang#57288

Stabilize --extern flag without a path. This stabilizes the `--extern` flag without a path, implemented in #54116. This flag is used to add a crate that may be found in the search path to the extern prelude. The intent of stabilizing this now is to change Cargo to emit this flag for `proc_macro` when building a proc-macro crate. This will allow the ability to elide `extern crate proc_macro;` for proc-macros, one of the few places where it is still necessary. It is intended that Cargo may also use this flag for other cases in the future as part of the [std-aware work](https://github.com/rust-lang/wg-cargo-std-aware/). There will likely be some kind of syntax where users may declare dependencies on other crates (such as `alloc`), and Cargo will use this flag so that they may be used like any other crate. At this time there are no short-term plans to use it for anything other than proc-macro. This will not help for non-proc-macro crates that use `proc_macro`, which I believe is not too common? An alternate approach for proc-macro is to use the `meta` crate, but from my inquiries there doesn't appear to be anyone interested in pushing that forward. The `meta` crate also doesn't help with things like `alloc` or `test`. cc #57288

rust-highfive assigned petrochenkov Sep 11, 2018

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 11, 2018

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 Sep 11, 2018