Regression importing log’s warn! macro inside of include!()ed file

[SimonSapin]

Cargo.toml

[package]
name = "foo"
version = "0.0.0"

[dependencies]
log = "0.4"

src/main.rs

include!("real_main.rs");

src/real_main.rs

#[macro_use] extern crate log;

fn main() {
    warn!("!!!");
}

Code like this used to build correctly:

$ rustup run --install nightly-2018-08-02 rustc -V 
rustc 1.29.0-nightly (97085f9fb 2018-08-01)
$ rustup run --install nightly-2018-08-02 cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.01s
     Running `target/debug/foo`

And now produces an error whose message seems wrong: it points at the call site of a macro as a "name also defined here":

$ rustup run --install nightly-2018-08-03 rustc -V
rustc 1.30.0-nightly (7e8ca9f8b 2018-08-03)
$ rustup run --install nightly-2018-08-03 cargo run
   Compiling foo v0.0.0 (file:///tmp/foo)
error[E0659]: `warn` is ambiguous
 --> src/real_main.rs:4:5
  |
4 |     warn!("!!!");
  |     ^^^^
  |
note: `warn` could refer to the name imported here
 --> src/real_main.rs:1:1
  |
1 | #[macro_use] extern crate log;
  | ^^^^^^^^^^^^
note: `warn` could also refer to the name defined here
 --> src/real_main.rs:4:5
  |
4 |     warn!("!!!");
  |     ^^^^
  = note: macro-expanded macro imports do not shadow

error: aborting due to previous error

For more information about this error, try `rustc --explain E0659`.
error: Could not compile `foo`.

To learn more, run the command again with --verbose.

Commit range between these two nightlies: 97085f9...7e8ca9f

#52841 is the only PR in the range that seems relevant. CC @petrochenkov, @alexcrichton

[SimonSapin]

#52841 (comment)

This is an expected breakage.
[…]
In this case macro expanded name (macro_rules macro warn from #[macro_use] extern crate log; inside include!() expansion) shadows a name from outer scope (built-in attribute warn from the language prelude)
[…]
built-in attributes can be somehow special-cased to avoid the error, or perhaps some more general solution can be found

It took me a few reads to find the key word "attribute" in this explanation, which refers to the lint-control one used for example as #[warn(unsafe_code)].

Why do function-like macros shadow attributes? (Even proc macro ones.) Shouldn’t they be in separate namespaces?

At the very least, the error message here is wrong. But avoiding the breakage entirely would be nice.

[petrochenkov]

Waiting on #53089

[petrochenkov]

an error whose message seems wrong: it points at the call site of a macro as a "name also defined here

Yeah, the diagnostics weren't properly adjusted for #52841

Why do function-like macros shadow attributes? (Even proc macro ones.) Shouldn’t they be in separate namespaces?

Well, this is an interesting question.
Macros are being modularized only now and the plan was to start conservatively with one namespace to avoid proliferation of namespaces.
Approach like this was okay for other namespaces, e.g. so far I haven't seen complaints about impl A for B { ... } not skipping A and searching further if A is a module, type or something else that's not a trait.

If the annoying cases like this continue to arise, we can move to "sub-namespaces" during relative path resolution (attributes are ignored when resolving non-attributes and vice versa, but use macro_name; still imports a single name for the whole macro namespace), or full-blown namespaces where use macro_name can import three (!!!) macros of different kinds at the same time.

---

It's also important to note that this particular case shouldn't even be a restricted shadowing error!

It's an error only because the restricted shadowing rules are very conservative and coarse-grained - we report an error if "macro-expanded macro shadows any other macro", but what we really want is to error on "more macro-expanded macro shadows less macro-expanded macro".
This is especially important for servo-like use cases when all the code is inside a macro (e.g. include!(...)).
In other words, this doesn't work right now, but it eventually should:

macro_rules! my_include {() => {
    macro m() {} // 1
    
    {
        macro m() {} // 2
        
        m!(); // ERROR `m` is ambiguous (1 or 2)
    }
}}

fn main() {
    my_include!();
}

[nikomatsakis]

Visiting for triage. Let's mark as P-high, but @petrochenkov seems to be on this.