[nightly regression] rustc incorrectly parses attributes as macro invocations in nightly-2018-08-18

[jchlapinski]

In the newest nightly all attributes with names identical to existing macros are parsed as macro invocation (note the lack of ! at the front of dummy in the example below).
Previous version nightly-2018-08-17 works as expected.
This breaks compilation of some of our custom derives, using same name for attributes and macros, which was previously allowed.

I tried this code:

macro_rules! dummy {
    ($x:expr) => {
        println!("dummy: {}", $x)
    }
}

#[dummy("text")] // this should not be regarded as a `dummy` macro invocation, should it?
struct SampleStruct {

}

fn main() {
    dummy!("text");
}

I expected this to complain about unknown custom attribute dummy

Instead, I got this error:

error: macro `dummy` may not be used in attributes
 --> src/main.rs:7:1
  |
7 | #[dummy("text")]
  | ^^^^^^^^^^^^^^^^

Meta

rustc --version --verbose:

rustc 1.30.0-nightly (33b923fd4 2018-08-18)
binary: rustc
commit-hash: 33b923fd44c5c5925e635815fce68bdf1f98740f
commit-date: 2018-08-18
host: x86_64-unknown-linux-gnu
release: 1.30.0-nightly
LLVM version: 7.0

[petrochenkov]

Currently this is expected behavior - fn-like macros, attribute macros and derive macros share single namespace and can shadow each other (similarly to types being able to shadow traits etc).
See #53205 (comment) for some motivation.

This change shouldn't affect stable Rust since attribute macros were stabilized only few days ago.

[jchlapinski]

... fn-like macros, attribute macros and derive macros share single namespace and can shadow each other (similarly to types being able to shadow traits etc).

Ok, but how is this #[dummy("aaa")] a "attribute macro" instead of just an fn-like attribute? My understanding is that in order for it to be an attribute macro it should read #[dummy!("aaa")], no?

[nikomatsakis]

@jchlapinski can you say a bit more about the actual code that is breaking for you?

cc @rust-lang/lang

[nikomatsakis]

Flagging this for @rust-lang/lang discussion -- do we want all macro_rules and other macros to be usable as macros in attribute position? It's certainly something we've talked about, but I thought it'd be good to "check in" on this.

[nikomatsakis]

In particular, if this is regressing code, it may not be something we can't really do. (Especially stable code -- it's still not clear to me just what the regressed code looks like.)

[Centril]

The error message seems a bit confusing as I think it leads the user to believe that dummy was called inside the attribute (so it would have been expanded to #[println!("dummy: {}", "text")].

If you actually wanted that behavior then the invocation should have been #[dummy!("text")] which may be useful for some sort of attribute-aliasing. However; I think such a step would require some more thinking into the design and possible alternatives, etc.

However, I think @petrochenkov's reasoning is right; this is not a stable-to-nightly regression because attribute macros were not previously stable. If you use an attribute name with the same name as a macro_rules macro, then the compiler is not to blame here imo.

See #53583 (comment) for why it is a stable-to-nightly-regression. @petrochenkov's solution seems like a good one provided that attribute proc macros can be renamed to deal with conflicts.

[jchlapinski]

@nikomatsakis basically we have custom derive for our diagnostic type trait Diag, which is using an fn-like attribute named diag and also a macro (defined with macro_rules) with that same name. Macro is for instantiation of out diagnostic type, where we do some backtrace generation, logging, etc.

Now we can of course change either name, however I still do not understand why using same name for attribute AND a macro would clash? By that same logic I can have a field and a method with the same name, since field access and method calls are easily discerned in parsing. Is there a different way to expand a macro, without suffixing macro name with a !?

[jchlapinski]

@Centril I am not blaming, I am just reasoning on why those things are sharing the same namespace. In my mind an attribute is something completely different than a macro. same logic for fields and methods as in my comment above.