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
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.
|
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
3 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.