-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Open
Labels
A-attributesArea: Attributes (`#[…]`, `#![…]`)Area: Attributes (`#[…]`, `#![…]`)A-macrosArea: All kinds of macros (custom derive, macro_rules!, proc macros, ..)Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..)A-resolveArea: Name/path resolution done by `rustc_resolve` specificallyArea: Name/path resolution done by `rustc_resolve` specificallyA-stabilityArea: `#[stable]`, `#[unstable]` etc.Area: `#[stable]`, `#[unstable]` etc.C-discussionCategory: Discussion or questions that doesn't represent real issues.Category: Discussion or questions that doesn't represent real issues.I-lang-radarItems that are on lang's radar and will need eventual work or consideration.Items that are on lang's radar and will need eventual work or consideration.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.T-langRelevant to the language teamRelevant to the language team
Description
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.
Metadata
Metadata
Assignees
Labels
A-attributesArea: Attributes (`#[…]`, `#![…]`)Area: Attributes (`#[…]`, `#![…]`)A-macrosArea: All kinds of macros (custom derive, macro_rules!, proc macros, ..)Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..)A-resolveArea: Name/path resolution done by `rustc_resolve` specificallyArea: Name/path resolution done by `rustc_resolve` specificallyA-stabilityArea: `#[stable]`, `#[unstable]` etc.Area: `#[stable]`, `#[unstable]` etc.C-discussionCategory: Discussion or questions that doesn't represent real issues.Category: Discussion or questions that doesn't represent real issues.I-lang-radarItems that are on lang's radar and will need eventual work or consideration.Items that are on lang's radar and will need eventual work or consideration.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.T-langRelevant to the language teamRelevant to the language team