Built-in macros, derives and attributes have inconsistent interactions with macros of the same name.

[alercah]

Macros currently occupy a single namespace, regardless of whether they are used for attributes, derives, or function-like macros. This was a design decision for procedural macros, on the basis that it is easier to split them into separate namespaces later, but it leads to some confusing interactions with built-in attributes (like cfg or derive), macros (like compile_error or env) or derives (like Eq or Clone). The behaviour should be tightened up so that it is intuitive and straightforward to explain.

---

Currently, the rules appear to be as follows:

• Macros can be defined that have the same name as a built-in attribute or macro. When used, the builtin takes precedence and the macro is ignored. If the macro is used in a different context, it is found and works normally (e.g. a function-like macro named derive can be called, or an attribute named compile_error can be used). Raw identifiers can be used to get around the built-in.
• Macros can be defined that have the same name as a built-in derive, except with proc_macro_derive. If a macro is defined with the same name as a built-in derive, it takes precedence. Defining a macro with proc_macro_derive that conflicts with the built-in gives an error at the definition.

If use_extern_macro is enabled, then you can freely rename imports. This lets you get around the proc_macro_derive rule:

#![feature(use_extern_macro)]

use failure::Fail as Clone;
use std::fmt::{Display, Formatter};

#[derive(Debug, Clone)]
struct Foo {
}

impl Display for Foo {
    fn fmt(&self, fmt : &mut Formatter) -> Result<(), std::fmt::Error> {
        write!(fmt, "{:?}", self)
    }
}

fn main() {
    let _ = Foo{}.cause();
}

Note that this behaviour applies only to built-in macros. Macros defined in libstd or libcore (for no_std) are imported in the prelude and can be overridden as one would expect for prelude names.

---

I do not think we can get away with treating all builtins as if they are normal names defined in the prelude that can be overridden. While it might be possible to treat some of them that way, the cfg attribute is an excellent example of one that cannot be safely modified, or else the following program would be problematic, because macro imports apply throughout the entire source file, not just after the import:

#[cfg(target_os = "linux")]
use some_crate::some_macro as cfg;

At the same time, I don't see why built-in derives should be special. The traits they implement are not, after all; even the ones like Copy which are magical. And it is possible, though inadvisable, to shadow them independently: trait Copy {} won't prevent #[derive(Copy)] from working, for instance.

This implies to me that we should have the following in the macro namespace:

1. Built-ins which are truly and deeply magical, and cannot safely be overridden. Their names are treated like keywords in the macro namespace, in that the same non-raw identifier cannot be used at all.
2. Intrinsics which are implemented by the compiler, but defined and named normally, like existing lang items and intrinsic functions.

This would imply the following behaviour changes:

1. proc_macro_derive can declare derives with the same name as an intrinsic derive; these will simply shadow the intrinsic.
2. Built-in function-like macros and attributes are always referred to when their names are used in the macro namespace, even in the wrong context, unless a raw identifier is used.
3. Macros of any kind cannot be declared with the same name as a built-in macro or attribute unless a raw identifier is used.
4. Going forward, we could possibly look at converting some built-in attributes and macros into intrinsics so that their names are freed up.

This leaves an unresolved question around renaming imports (e.g. use foo::bar as cfg; where foo::bar is names both a function and macro; is this an error? warning? or it just silently hides the macro as r#cfg?) but would clean up the bulk of the issues with the situation.

[petrochenkov]

I'm going to implement roughly the same scheme as described here, because it's currently used for non-macro namespaces (I described it previously in the tool attributes RFC - rust-lang/rfcs#2103 (comment)).

• User-defined names are, well, user-defined and modularized.
• Macros defined in the standard library (including perhaps procedural ones in the future, moved to the library from the compiler!) are introduced through standard library prelude, with lower priority than user-defined names during in-scope resolution (#[macro_use] extern crate ... and preludes are the same mechanism).
• Builtin macros (including derives) and attributes are introduced through language prelude, with even lower priority, in the same way as primitive types like u8 or bool.

If something currently diverges from this scheme, e.g. builtin something shadows user-defined something, then it's a bug and it should be reported (preferably in a separate focused issue with reproduction).

The only tricky case here is attributes that need to be inspected before name resolution, like #[feature(...)] or, as you've mentioned, #[cfg(...)].
Perhaps a few attributes will need to be reserved and not resolved, or perhaps they'll be interpreted as tokens first, but then resolved normally, I think it'll become cleared during implementation.

[djrenren]

Currently attributes exist in another namespace so if we implement overriding of attributes it'll be a breaking change.

Right now you can have both a macro_rules! test and a #[test] attribute. Allowing overriding (which seems like the right call to me) would break any code that has both because they'd be in the same namespace. We even do this in the compiler: https://github.com/rust-lang/rust/blob/master/src/libsyntax_pos/analyze_filemap.rs

[petrochenkov]

My plan was to implement the principled scheme first, then run it through crater and look how much code breaks on stable, what cases of breakage are common, and then make adjustments.

[djrenren]

Sounds like a good plan. I've run into this issue while working on custom test frameworks so mind if I take a crack at it?

[petrochenkov]

@djrenren
Yes, it would be good if more people got familiar with this code.
However, I'm currently working on #52512 and #44690 which are closely related to this issue and are prerequisites in some sense, and hope to start working on this issue this weekend.

There's one piece of work that's relatively independent though.
There's a number of locations that accept attributes, but cannot be inputs to macros, for example generic parameters fn f<#[my_attr] T>() {} (the full list can be found in #52367 (comment) or in ast.rs).
We need to go through all these attributes, resolve them and report an error if resolution does not refer to an "inert" attribute (builtin, custom or tool attribute).

[djrenren]

Sweet I'll take a look at it.