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

@ehuss

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:

(T-compiler) Built-in attributes like #[coverage(..)] are handled differently versus prelude attributes like #[test], including name resolution.
(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).
(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.

@rustbot

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

@rustbot

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

#53913 has relevant information about the current behavior.

cc #133708

related: #t-lang-docs/reference > name resolution @ 💬

Related discussion: #t-lang > Name Res: questions on intended behavior @ 💬

Here's an explanation of the original change that did this (the ticket is linked above, but this is the specific comment):
#53913 (comment)

Rename `#[unroll]` => `#[rustc_unroll]` to mitigate nameres ambiguity

Navigation Menu

Repository navigation

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 #134963

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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 #134963

Description

Activity

jieyouxu commented on Dec 31, 2024

apiraino commented on Jan 15, 2025

petrochenkov commented on Jan 15, 2025

jieyouxu commented on Jul 15, 2025

yaahc commented on Dec 5, 2025

jieyouxu commented on Jul 18, 2026

teor2345 commented on Jul 19, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions