`use proc_macro` regressed from nightly-2018-09-14 to nightly 2018-09-15 in edition 2018

[LukasKalbertodt]

Use statements for proc_macro that worked in nightly-(2ab3eba 2018-09-14) don't work in (e4ba1d4 2018-09-15) (including all newer nightlies up to at least (3bc2ca7 2018-09-20) and the RC1 beta) anymore.

I tried this code:

src/lib.rs

use proc_macro::TokenStream;

#[proc_macro]
pub fn foo(input: TokenStream) -> TokenStream {
    input
}

Cargo.toml

[package]
name = "proc-fail"
version = "0.1.0"
authors = ["me"]
edition = "2018"

[lib]
proc-macro = true

[dependencies]

As said, compiling with (2ab3eba 2018-09-14), everything works. But compiling with (e4ba1d4 2018-09-15) results in:

Error (1)

error[E0432]: unresolved import `proc_macro`
 --> src/lib.rs:3:5
  |
3 | use proc_macro::TokenStream;
  |     ^^^^^^^^^^ Could not find `proc_macro` in `{{root}}`

---

I tried different configurations with the two different nightly versions. The error in edition = "2015" without the extern crate is expected, of course (or is it? I'm confused now).

With nightly-(2ab3eba 2018-09-14):

	edition = "2015"	edition = "2018"
with extern crate proc_macro	works	works
without extern crate proc_macro	fails (3)	works

With nightly- (e4ba1d4 2018-09-15):

	edition = "2015"	edition = "2018"
with extern crate proc_macro	works	fails (2)
without extern crate proc_macro	fails (3)	fails (1) (the case described above)

Error (2)

error[E0432]: unresolved import `proc_macro`
 --> src/lib.rs:3:5
  |
3 | use proc_macro::TokenStream;
  |     ^^^^^^^^^^ Did you mean `self::proc_macro`?

Error (3)

error[E0432]: unresolved import `proc_macro`
 --> src/lib.rs:3:5
  |
3 | use proc_macro::TokenStream;
  |     ^^^^^^^^^^ Did you mean `registrar::proc_macro`?

---

I couldn't really find any information about this. So the only way to make it work right now is to either use edition 2015 with extern crate or edition 2018 with extern crate and use self::proc_macro.

Is this intended or an unwanted regression?

[petrochenkov]

@LukasKalbertodt

Is this intended or an unwanted regression?

Intended, #54116 is the relevant PR.

[LukasKalbertodt]

@petrochenkov Thanks!

So what's the intended solution for Rust 2018 now? extern crate proc_macro; use self::proc_macro? That seems wrong :/
As I understand it, meta is only a placeholder and not yet usable.

[petrochenkov]

Yes, for now extern crate proc_macro; is the solution on stable, until --extern crate_name is stabilized in some form.

[LukasKalbertodt]

@petrochenkov But just adding extern crate proc_macro; doesn't solve the problem. Here as a full example again:

src/lib.rs

extern crate proc_macro;

use proc_macro::TokenStream;


#[proc_macro]
pub fn foo(input: TokenStream) -> TokenStream {
    input
}

Cargo.toml

[package]
name = "proc-fail"
version = "0.1.0"
authors = ["me"]
edition = "2018"

[lib]
proc-macro = true

[dependencies]

Executing cargo +nightly-2018-09-16 build results in (note nightly-2018-09-16 is (e4ba1d41e 2018-09-15)):

error[E0432]: unresolved import `proc_macro`
 --> src/lib.rs:3:5
  |
3 | use proc_macro::TokenStream;
  |     ^^^^^^^^^^ Did you mean `self::proc_macro`?

Is this also intended?

[petrochenkov]

@LukasKalbertodt
No, this is not intended.

Minimal reproduction:

// --edition 2018
extern crate proc_macro;
use proc_macro::TokenStream; // ERROR unresolved import `proc_macro`

fn main() {}

cc @eddyb

[petrochenkov]

Workaround:

// --edition 2018
extern crate proc_macro;
use crate::proc_macro::TokenStream; // OK

fn main() {}

[eddyb]

We can't make extern crate extend the extern prelude, can we? I haven't seen a plan for doing so, or how it would be sound wrt fixpoint searches.

[petrochenkov]

@eddyb
The question is why use proc_macro::... doesn't resolve to proc_macro from the current module (self::proc_macro) introduced by the extern crate item.

[petrochenkov]

Oh, crap.
feature(uniform_path) is still not enabled by default.

[petrochenkov]

So, yes, with "anchored path" model (#53130) this works as intended, even if it looks pretty bad.

[LukasKalbertodt]

@petrochenkov Ahhh ok, now I get it. That makes sense, even if it's a bit unfortunate. So I will just use self::proc_macro for now.