Rename #[unroll] => #[rustc_unroll] to mitigate nameres ambiguity - #160211
Rename #[unroll] => #[rustc_unroll] to mitigate nameres ambiguity#160211jieyouxu wants to merge 5 commits into
#[unroll] => #[rustc_unroll] to mitigate nameres ambiguity#160211Conversation
|
Some changes occurred in compiler/rustc_hir/src/attrs cc @jdonszelmann, @JonathanBrouwer Some changes occurred in compiler/rustc_attr_parsing |
rustbot
added
A-attributes
|
r? @mati865 rustbot has assigned @mati865. Use Why was this reviewer chosen?The reviewer was selected based on:
|
jieyouxu
added
the
beta-nominated
|
NB: nominated for T-lang in case they want to FCP-accept the breakage in #159429 (comment), but we should beta-backport this PR if T-lang doesn't make a call by the week before next stable. |
|
r=me if you want to workaround it ASAP, but IMO we can wait for nightly As I said on Zulip, merging it for beta is reasonable to me. |
I will merge / time this around the week before next stable release week, approx. 2026-08-12 or 2026-08-13 ish. If T-lang makes no decision by then, I will merge this PR and tag this beta-accepted. |
jieyouxu
added
S-waiting-on-author
This comment has been minimized.
This comment has been minimized.
Mitigation for [RUST-159429]. The recurring problem is that built-in attributes are treated differently compared to ordinary prelude attributes, built-in attributes, even while unstable, can name-collide with stable macro re-exports of the same name (and proc-macro helper attributes of the same name), which can break stable code. See [RUST-134964]. [RUST-159429]: rust-lang#159429 [RUST-134963]: rust-lang#134963
To account for the renamed `#[rustc_unroll]` attribute.
This stderr diff is a funny side-effect of renaming `#[unroll]` => `#[rustc_unroll]`, where the `#[rustc_unknown]` attribute name is just similar enough edit distance wise to `#[rustc_unroll]` that `#[rustc_unroll]` shows up as a plausible suggestion candidate, lol.
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
rust-bors
Bot
added
S-waiting-on-bors
|
beta backport approved as per compiler team on Zulip. A backport PR will be authored by the release team at the end of the current development cycle. Backport labels are handled by them. |
rustbot
added
the
beta-accepted
|
More prior art: There was a little bit of nameres ambiguity breakage reported when As far as I can tell, no remedial action was taken in that case. |
Rename `#[unroll]` => `#[rustc_unroll]` to mitigate nameres ambiguity ## Summary Mitigate rust-lang#159429 by renaming `#[unroll]` => `#[rustc_unroll]`. Did not bother with a regression test, because a regression test would be hedging against an unknown attribute if `#[unroll]` later proceeds to get a different name. Tracking issue for `#![feature(loop_hints)]`: rust-lang#156874. ## Rationale Even while the crater-observed fallout seems to be relatively small, we'd like such nameres ambiguity breakages to be *deliberate* (read: T-lang FCP'd) rather than accidental (discovered through beta crater runs). See discussions around [last week's compiler triage meeting](https://rust-lang.zulipchat.com/#narrow/channel/238009-t-compiler.2Fmeetings/topic/.5Bweekly.5D.202026-07-23/near/612371735). ## Background context The recurring problem is that built-in attributes are treated differently compared to ordinary prelude attributes, built-in attributes, even while unstable, can name-collide with stable macro re-exports of the same name (and proc-macro helper attributes of the same name), which can break stable code. See rust-lang#134964. See also: - rust-lang#133708 - rust-lang#53913 (comment) - https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/Name.20Res.3A.20questions.20on.20intended.20behavior/near/562001319 - rust-lang#143834 (comment) ## Prior Art - For `#[align]`, breakage was more wide-spread, so we posted this same mitigation here: rust-lang#144080. - For `#[sanitize]`, T-lang explicitly FCP'd the breakage stemming from renaming `#[no_sanitize]` (old name) to `#[sanitize]` (new name) that regressed a couple of crates: rust-lang#142681 (comment). ## Alternatives to this PR Generally: - We let it slide. - T-lang FCP on `#[unroll]` breakage (in which case this PR should be closed). - FCP another name (and associated breakages). - (Hard) Fix the built-in attribute name resolution behavior. I have no particular preference on the approaches myself, any of this PR and the alternatives seem fine so as long as the breakage is *deliberate* not accidental.
4 participants
Summary
Mitigate #159429 by renaming
#[unroll]=>#[rustc_unroll].Did not bother with a regression test, because a regression test would be hedging against an unknown attribute if
#[unroll]later proceeds to get a different name.Tracking issue for
#![feature(loop_hints)]: #156874.Rationale
Even while the crater-observed fallout seems to be relatively small, we'd like such nameres ambiguity breakages to be deliberate (read: T-lang FCP'd) rather than accidental (discovered through beta crater runs).
See discussions around last week's compiler triage meeting.
Background context
The recurring problem is that built-in attributes are treated differently compared to ordinary prelude attributes, built-in attributes, even while unstable, can name-collide with stable macro re-exports of the same name (and proc-macro helper attributes of the same name), which can break stable code. See #134964.
See also:
#[macro_export]'edmacro_rules!macros are impossible to disambiguate from built-in attributes inusedeclarations #133708alignis ambiguous #143834 (comment)Prior Art
#[align], breakage was more wide-spread, so we posted this same mitigation here: Mitigate#[align]name resolution ambiguity regression with a rename #144080.#[sanitize], T-lang explicitly FCP'd the breakage stemming from renaming#[no_sanitize](old name) to#[sanitize](new name) that regressed a couple of crates: Remove the#[no_sanitize]attribute in favor of#[sanitize(xyz = "on|off")]#142681 (comment).Alternatives to this PR
Generally:
#[unroll]breakage (in which case this PR should be closed).I have no particular preference on the approaches myself, any of this PR and the alternatives seem fine so as long as the breakage is deliberate not accidental.