Built-in attributes are treated differently vs prelude attributes, unstable built-in attributes can name-collide with stable macro, and built-in attributes can break back-compat

[jieyouxu]

Example breakage: Broken build after updating: coverage is ambiguous; ambiguous because of a name conflict with a builtin attribute

Example code:

macro_rules! coverage {
    () => {
        /* .. */
    };
}

pub(crate) use coverage; // `use` here becomes ambiguous

test is similar to a proc-macro, which is exposed via the prelude. It is not a "built-in" attribute.

The reference hasn't really been updated from when that changed. The sub-namespace section also probably should be clearer on what it means to shadow. I also don't have a good explanation why a prelude attribute is treated differently from a built-in one.

Originally posted by @ehuss in #121157

This is an interesting problem that has three aspects:

1. (T-compiler) Built-in attributes like #[coverage(..)] are handled differently versus prelude attributes like #[test], including name resolution.
2. (T-compiler) Current feature-gating of unstable built-in attributes is insufficient: adding a new unstable built-in attribute gated behind a feature gate (e.g. #[coverage]) can still break stable code without any feature gates (e.g. use of a user-defined macro of the same name as the newly added built-in attribute).
3. (T-compiler, T-lang) Stabilization of a built-in attribute can break backwards compatibility: old code can be broken by addition of a new built-in attribute.

It might be tricky to change (or not possible), mostly opened this issue for awareness.

[jieyouxu]

Nominating for T-compiler discussion, mostly for awareness and if there's anything actionable (feel free to postpone this until holiday is over, just putting it in the nomination queue).

@rustbot label +I-compiler-nominated

[apiraino]

We briefly looked at this during T-compiler triage on Zulip.

One question was what is precisely meant by stability of the built-ins to rustc, seems we don't have a good summary for it, we should probably have this behaviour documented somewhere.

Removing the nomination for now. In case feel free to nominate for T-compiler discussion again.
@rustbot label -I-compiler-nominated

[petrochenkov]

#53913 has relevant information about the current behavior.