Rename `#[unroll]` => `#[rustc_unroll]` to mitigate nameres ambiguity by jieyouxu · Pull Request #160211 · rust-lang/rust

jieyouxu · 2026-07-30T11:47:44Z

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.

Prior Art

For #[align], breakage was more wide-spread, so we posted this same mitigation here: Mitigate #[align] name resolution ambiguity regression with a rename #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: Remove the #[no_sanitize] attribute in favor of #[sanitize(xyz = "on|off")] #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.

rustbot · 2026-07-30T11:47:48Z

Some changes occurred in compiler/rustc_hir/src/attrs

cc @jdonszelmann, @JonathanBrouwer

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann, @JonathanBrouwer

rustbot · 2026-07-30T11:47:51Z

r? @mati865

rustbot has assigned @mati865.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: compiler
compiler expanded to 74 candidates
Random selection from 16 candidates

jieyouxu · 2026-07-30T14:40:33Z

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.

mati865 · 2026-07-30T14:54:26Z

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.

jieyouxu · 2026-07-30T15:01:34Z

r=me if you want to workaround it ASAP, but IMO we can wait for nightly

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.

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.

rustbot · 2026-08-06T01:24:15Z

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.

jieyouxu · 2026-08-06T01:26:45Z

Fixed trivial merge conflict, no changes.

Looks like lang consensus seems to be a rename mitigation at this moment based on comment and comment, so I will send this PR off to the queue and mark this beta-accepted, as discussed.

@bors r=mati865 rollup

rust-bors · 2026-08-06T01:26:48Z

📌 Commit d1265b7 has been approved by mati865

It is now in the queue for this repository.

rustbot · 2026-08-06T01:27:26Z

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.

Zalathar · 2026-08-06T04:25:19Z

More prior art: There was a little bit of nameres ambiguity breakage reported when #[no_coverage] was renamed to #[coverage(off)] (still unstable)

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

As far as I can tell, no remedial action was taken in that case.

(via Zulip history)

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.

…uwer Rollup of 17 pull requests Successful merges: - #159530 (Cap socket send length to c_int::MAX on Apple targets) - #159506 (Allow associated const equality constraints with GCA) - #160006 (Account for desugaring in method call move errors) - #160415 (Split `aarch64-apple{,-macos-26}` => `aarch64-apple{,-macos-26}-{1,2}` jobs) - #160464 (fix: Check the fallback map before queueing child in `visible_parent_map` breadth-first search) - #160555 (Split `apply_primary_terminator_effect`) - #160592 (Suggest if-let chain continuation on unclosed delimiter) - #160600 (Avoid the std DLL copy alongside rustc) - #160156 (check_consts: exhaustively match on CastKind) - #160211 (Rename `#[unroll]` => `#[rustc_unroll]` to mitigate nameres ambiguity) - #160304 (Add tests for fixed new solver issues) - #160398 (rustc_abi: Add `LayoutData::is_variant_uninhabited` method) - #160546 (Update error message in documentation comments) - #160568 (Use `VisitorResult` helper macros) - #160571 (Add regression test for array type recovery in generic arguments) - #160588 (add a test showing polonius alpha is not a subset of datalog polonius) - #160617 (Add a suggestion to MissingUnsafeOnExtern diagnostic)

Rollup merge of #160211 - jieyouxu:froot-loops, r=mati865 Rename `#[unroll]` => `#[rustc_unroll]` to mitigate nameres ambiguity ## 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](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 #134964. See also: - #133708 - #53913 (comment) - https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/Name.20Res.3A.20questions.20on.20intended.20behavior/near/562001319 - #143834 (comment) ## Prior Art - For `#[align]`, breakage was more wide-spread, so we posted this same mitigation here: #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: #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.

jieyouxu added the F-loop-hints `#![feature(loop_hints)]` label Jul 30, 2026

rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 30, 2026

rustbot assigned mati865 Jul 30, 2026

jieyouxu mentioned this pull request Jul 30, 2026

1.98 beta regression due to name collision with unroll #159429

Open

jieyouxu added the beta-nominated Nominated for backporting to the compiler in the beta channel. label Jul 30, 2026

mati865 approved these changes Jul 30, 2026

View reviewed changes

jieyouxu added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 30, 2026

This comment has been minimized.

Sign in to view

jieyouxu added 5 commits August 6, 2026 09:23

Update attr name in #[unroll] codegen-llvm tests

44d291e

Update attr name in #[unroll] ui tests

91ee1f3

To account for the renamed `#[rustc_unroll]` attribute.

Update attr name for #[unroll] in Unstable Book

d1265b7

jieyouxu force-pushed the froot-loops branch from 3defc96 to d1265b7 Compare August 6, 2026 01:24

rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 6, 2026

rustbot added the beta-accepted Accepted for backporting to the compiler in the beta channel. label Aug 6, 2026

jhpratt mentioned this pull request Aug 6, 2026

Rollup of 7 pull requests #160601

Closed

JonathanBrouwer mentioned this pull request Aug 6, 2026

Rollup of 13 pull requests #160609

Closed

JonathanBrouwer mentioned this pull request Aug 6, 2026

Rollup of 13 pull requests #160610

Closed

JonathanBrouwer mentioned this pull request Aug 6, 2026

Rollup of 17 pull requests #160615

Closed

This was referenced Aug 6, 2026

Rollup of 16 pull requests #160623

Closed

Rollup of 17 pull requests #160627

Merged

rust-bors Bot merged commit 25fd483 into rust-lang:main Aug 6, 2026
13 checks passed

rustbot added this to the 1.99.0 milestone Aug 6, 2026

Navigation Menu

Uh oh!

Uh oh!

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

Rename `#[unroll]` => `#[rustc_unroll]` to mitigate nameres ambiguity#160211
rust-bors[bot] merged 5 commits into
rust-lang:mainfrom
jieyouxu:froot-loops

jieyouxu commented Jul 30, 2026 •

edited

Loading

Uh oh!

rustbot commented Jul 30, 2026

Uh oh!

rustbot commented Jul 30, 2026

Uh oh!

jieyouxu commented Jul 30, 2026

Uh oh!

mati865 commented Jul 30, 2026

Uh oh!

jieyouxu commented Jul 30, 2026

Uh oh!

This comment has been minimized.

rustbot commented Aug 6, 2026

Uh oh!

jieyouxu commented Aug 6, 2026

Uh oh!

rust-bors Bot commented Aug 6, 2026

Uh oh!

rustbot commented Aug 6, 2026

Uh oh!

Zalathar commented Aug 6, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Uh oh!

Conversation

jieyouxu commented Jul 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Rationale

Background context

Prior Art

Alternatives to this PR

Uh oh!

rustbot commented Jul 30, 2026

Uh oh!

rustbot commented Jul 30, 2026

Uh oh!

jieyouxu commented Jul 30, 2026

Uh oh!

mati865 commented Jul 30, 2026

Uh oh!

jieyouxu commented Jul 30, 2026

Uh oh!

This comment has been minimized.

rustbot commented Aug 6, 2026

Uh oh!

jieyouxu commented Aug 6, 2026

Uh oh!

rust-bors Bot commented Aug 6, 2026

Uh oh!

rustbot commented Aug 6, 2026

Uh oh!

Zalathar commented Aug 6, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

jieyouxu commented Jul 30, 2026 •

edited

Loading