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

[NicholasGorski]

Code

I have an internal macro for domain-specific coverage tracking:

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

pub(crate) use coverage;

On version 1.73.0, this compiles without error (godbolt).
On version 1.74.0 and above, this results in an error (godbolt):

error[E0659]: `coverage` is ambiguous
 --> <source>:7:16
  |
7 | pub(crate) use coverage;
  |                ^^^^^^^^ ambiguous name
  |
  = note: ambiguous because of a name conflict with a builtin attribute
  = note: `coverage` could refer to a built-in attribute

My understanding is that this is an acceptable breakage in general. (Though, perhaps should be in the 1.74.0 compatibility notes).

However, what might make this unacceptable is that this attribute is not actually stable:

#[coverage(off)]
pub fn foo() {}

gives (godbolt):

error[E0658]: the `#[coverage]` attribute is an experimental feature
 --> <source>:1:1
  |
1 | #[coverage(off)]
  | ^^^^^^^^^^^^^^^^
  |
  = note: see issue #84605 <https://github.com/rust-lang/rust/issues/84605> for more information
  = help: add `#![feature(coverage_attribute)]` to the crate

Is it expected that an inactive experimental attribute can cause name ambiguity on stable Rust?

[apiraino]

searched nightlies: from nightly-2023-08-20 to nightly-2024-02-17
regressed nightly: nightly-2023-09-15
searched commit range: 8142a31...ca2b74f
regressed commit: c728bf3

bisected with cargo-bisect-rustc v0.6.7

Host triple: x86_64-unknown-linux-gnu
Reproduce with:

cargo bisect-rustc --start=1.73.0 --without-cargo --preserve --script=./test.sh 

cc @bossmc @oli-obk was this a slip or was intentional and just missed the release notes?

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-medium

[oli-obk]

Definitely unintentional. But it also means the feature gating of no_coverage (and possibly other builtin unstable attributes), aren't correctly gated

[bossmc]

Totally agree with oli-obk, I wouldn't expect/want this to impact stable rust until the feature stabilizes. I'm not an expert on the feature-gating system in rustc, but I'd hope there's a way to ignore attributes "hidden" behind unstable features.

In general, is it ok to introduce new attributes like this? This causes compile errors by reserving a name in the "global" macro namespace it feels like it's quite similar to defining a new keyword (not quite as limiting maybe, since it only clashes in the macro namespace, but there's no way to not import builtin attributes). Is this a thing that's been considered before? Does stabilization need to wait for edition 2024?