use `#[align]` attribute for `fn_align` #142507

folkertdev · 2025-06-14T14:26:28Z

Tracking issue: #82232

rust-lang/rfcs#3806 decides to add the #[align] attribute for alignment of various items. Right now it's used for functions with fn_align, in the future it will get more uses (statics, struct fields, etc.)

(the RFC finishes FCP today)

r? @ghost

folkertdev · 2025-06-15T11:15:06Z

@traviscross the FCP on #[align] is completed, but there is some discussion over there. I haven't seen anyone object to using #[align] though. Can we move forward with the attribute name change here (and then stabilize #140261), or should T-lang discuss the attribute change again first?

traviscross · 2025-06-15T18:42:41Z

Given the RFC acceptance, this change is good to go as a lang matter.

folkertdev

Nice, in that case

r? @jdonszelmann

compiler/rustc_passes/src/errors.rs

compiler/rustc_attr_parsing/src/attributes/repr.rs

rustbot · 2025-06-15T19:29:39Z

The Miri subtree was changed

cc @rust-lang/miri

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

Some changes occurred in compiler/rustc_codegen_ssa/src/codegen_attrs.rs

cc @jdonszelmann

Some changes occurred in compiler/rustc_passes/src/check_attr.rs

cc @jdonszelmann

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann

Some changes occurred in compiler/rustc_attr_data_structures

cc @jdonszelmann

jdonszelmann · 2025-06-15T20:19:43Z

On my to-do list! Will take a look somewhere this week :)

compiler/rustc_attr_parsing/src/attributes/repr.rs

jdonszelmann · 2025-06-15T22:29:16Z

compiler/rustc_attr_parsing/src/attributes/repr.rs

+        cx: &'c mut AcceptContext<'_, '_, S>,
+        args: &'c ArgParser<'_>,
+    ) {
+        // The builtin attributes parser already emits an error in this case.


by the template logic? I'd quite like to move those checks here at some point, including the templates. For converted attributes I usually have added an exception there to ignore attributes with new-style parsers so that these checks do do something, and all checks happen in one place. If you wouldn't mind, could you do the same for align?

With #138165 you don't need to make a new diagnostic for this either which should make your life easier.

by the template logic?

Exactly

If you wouldn't mind, could you do the same for align?

Do you have an example here? E.g ConfusablesParser also seems to ignore this case?

yea! I've been making exceptions to new attributes here:

rust/compiler/rustc_parse/src/validate_attr.rs

Line 288 in 1e8aac1

sym::inline

and then add proper validation for them here:

rust/compiler/rustc_attr_parsing/src/attributes/inline.rs

Line 24 in 1e8aac1

match args {

(n.b. I exhaustively match and error on all cases)

I think those links are to #138165? Should I rebase on that now? (happy to, but could also do a follow-up later)

I think rebasing would be nice, then this parser is in a much nicer state. Otherwise I'll go back to fix it next week again. That #138165 seems to make good progress.

compiler/rustc_attr_parsing/src/attributes/repr.rs

compiler/rustc_codegen_ssa/src/codegen_attrs.rs

compiler/rustc_passes/src/check_attr.rs

jdonszelmann · 2025-06-15T22:39:09Z

compiler/rustc_passes/src/check_attr.rs

-                                    fluent::passes_repr_align_function,
-                                )
-                                .emit();
+                                self.dcx().emit_err(errors::ReprAlignShouldBeAlign {


love these helpful diagnostics :)

compiler/rustc_passes/src/errors.rs

bors · 2025-06-16T22:20:09Z

☔ The latest upstream changes (presumably #142589) made this pull request unmergeable. Please resolve the merge conflicts.

jdonszelmann · 2025-06-18T09:31:04Z

@folkertdev master now has these changes to diagnostics :)

Right now it's used for functions with `fn_align`, in the future it will get more uses (statics, struct fields, etc.)

jdonszelmann · 2025-06-18T12:00:25Z

much better

jdonszelmann · 2025-06-18T12:02:24Z

@bors rollup=always

bors · 2025-06-18T12:02:26Z

📌 Commit 1fdf2b5 has been approved by jdonszelmann

It is now in the queue for this repository.

Rollup of 7 pull requests Successful merges: - #140247 (Don't build `ParamEnv` and do trait solving in `ItemCtxt`s when lowering IATs) - #142507 (use `#[align]` attribute for `fn_align`) - #142524 (Weekly `cargo update`) - #142606 (AsyncDrop trait without sync Drop generates an error) - #142639 (Add a missing colon at the end of the panic location details in location-detail-unwrap-multiline.rs) - #142654 (library: Increase timeout on mpmc test to reduce flakes) - #142692 (Assorted bootstrap cleanups (step 3)) r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of #142507 - folkertdev:fn-align-align-attribute, r=jdonszelmann use `#[align]` attribute for `fn_align` Tracking issue: #82232 rust-lang/rfcs#3806 decides to add the `#[align]` attribute for alignment of various items. Right now it's used for functions with `fn_align`, in the future it will get more uses (statics, struct fields, etc.) (the RFC finishes FCP today) r? `@ghost`

Rollup of 7 pull requests Successful merges: - rust-lang/rust#140247 (Don't build `ParamEnv` and do trait solving in `ItemCtxt`s when lowering IATs) - rust-lang/rust#142507 (use `#[align]` attribute for `fn_align`) - rust-lang/rust#142524 (Weekly `cargo update`) - rust-lang/rust#142606 (AsyncDrop trait without sync Drop generates an error) - rust-lang/rust#142639 (Add a missing colon at the end of the panic location details in location-detail-unwrap-multiline.rs) - rust-lang/rust#142654 (library: Increase timeout on mpmc test to reduce flakes) - rust-lang/rust#142692 (Assorted bootstrap cleanups (step 3)) r? `@ghost` `@rustbot` modify labels: rollup

…=jdonszelmann correct template for `#[align]` attribute Tracking issue: rust-lang#82232 related: rust-lang#142507 I didn't fully understand what `template!` did, clearly. An empty `#[align]` attribute was still rejected later, but without this change it does get suggested in certain cases. I've also updated some outdated references to `#[repr(align)]` on functions. r? `@jdonszelmann`

…=jdonszelmann correct template for `#[align]` attribute Tracking issue: rust-lang#82232 related: rust-lang#142507 I didn't fully understand what `template!` did, clearly. An empty `#[align]` attribute was still rejected later, but without this change it does get suggested in certain cases. I've also updated some outdated references to `#[repr(align)]` on functions. r? ``@jdonszelmann``

Rollup merge of #142715 - folkertdev:fn-align-corrections, r=jdonszelmann correct template for `#[align]` attribute Tracking issue: #82232 related: #142507 I didn't fully understand what `template!` did, clearly. An empty `#[align]` attribute was still rejected later, but without this change it does get suggested in certain cases. I've also updated some outdated references to `#[repr(align)]` on functions. r? ``@jdonszelmann``

apiraino · 2025-07-14T10:07:01Z

Suggesting for release notes, see comment.

@rustbot label relnotes

jieyouxu · 2025-07-17T16:41:03Z

Untagging as relnotes because we're considering a rename mitigation instead: #143834 (comment)

Mitigate `#[align]` name resolution ambiguity regression with a rename Mitigates beta regression rust-lang#143834 after a beta backport. ### Background on the beta regression The name resolution regression arises due to rust-lang#142507 adding a new feature-gated built-in attribute named `#[align]`. However, unfortunately even [introducing new feature-gated unstable built-in attributes can break user code](https://www.github.com/rust-lang/rust/issues/134963) such as ```rs macro_rules! align { () => { /* .. */ }; } pub(crate) use align; // `use` here becomes ambiguous ``` ### Mitigation approach This PR renames `#[align]` to `#[rustc_align]` to mitigate the beta regression by: 1. Undoing the introduction of a new built-in attribute with a common name, i.e. `#[align]`. 2. Renaming `#[align]` to `#[rustc_align]`. The renamed attribute being `rustc_align` will not introduce new stable breakages, as attributes beginning with `rustc` are reserved and perma-unstable. This does mean existing nightly code using `fn_align` feature will additionally need to specify `#![feature(rustc_attrs)]`. This PR is very much a short-term mitigation to alleviate time pressure from having to fully fix the current limitation of inevitable name resolution regressions that would arise from adding any built-in attributes. Long-term solutions are discussed in [#t-lang > namespacing macro attrs to reduce conflicts with new adds](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/namespacing.20macro.20attrs.20to.20reduce.20conflicts.20with.20new.20adds/with/529249622). ### Alternative mitigation options [Various mitigation options were considered during the compiler triage meeting](rust-lang#143834 (comment)), and those consideration are partly reproduced here: - Reverting the PR doesn't seem very minimal/trivial, and carries risks of its own. - Rename to a less-common but aim-to-stabilization name is itself not safe nor convenient, because (1) that risks introducing new regressions (i.e. ambiguity against the new name), and (2) lang would have to FCP the new name hastily for the mitigation to land timely and have a chance to be backported. This also makes the path towards stabilization annoying. - Rename the attribute to a rustc attribute, which will be perma-unstable and does not cause new ambiguities in stable code. - This alleviates the time pressure to address *this* regression, or for lang to have to rush an FCP for some new name that can still break user code. - This avoids backing out a whole implementation. ### Review advice This PR is best reviewed commit-by-commit. - Commit 1 adds a test `tests/ui/attributes/fn-align-nameres-ambiguity-143834.rs` which demonstrates the current name resolution regression re. `align`. This test fails against current master. - Commit 2 carries out the renames and test reblesses. Notably, commit 2 will cause `tests/ui/attributes/fn-align-nameres-ambiguity-143834.rs` to change from fail (nameres regression) to pass. This PR, if the approach still seems acceptable, will need a beta-backport to address the beta regression.

Rollup merge of #144080 - jieyouxu:realign, r=BoxyUwU Mitigate `#[align]` name resolution ambiguity regression with a rename Mitigates beta regression #143834 after a beta backport. ### Background on the beta regression The name resolution regression arises due to #142507 adding a new feature-gated built-in attribute named `#[align]`. However, unfortunately even [introducing new feature-gated unstable built-in attributes can break user code](https://www.github.com/rust-lang/rust/issues/134963) such as ```rs macro_rules! align { () => { /* .. */ }; } pub(crate) use align; // `use` here becomes ambiguous ``` ### Mitigation approach This PR renames `#[align]` to `#[rustc_align]` to mitigate the beta regression by: 1. Undoing the introduction of a new built-in attribute with a common name, i.e. `#[align]`. 2. Renaming `#[align]` to `#[rustc_align]`. The renamed attribute being `rustc_align` will not introduce new stable breakages, as attributes beginning with `rustc` are reserved and perma-unstable. This does mean existing nightly code using `fn_align` feature will additionally need to specify `#![feature(rustc_attrs)]`. This PR is very much a short-term mitigation to alleviate time pressure from having to fully fix the current limitation of inevitable name resolution regressions that would arise from adding any built-in attributes. Long-term solutions are discussed in [#t-lang > namespacing macro attrs to reduce conflicts with new adds](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/namespacing.20macro.20attrs.20to.20reduce.20conflicts.20with.20new.20adds/with/529249622). ### Alternative mitigation options [Various mitigation options were considered during the compiler triage meeting](#143834 (comment)), and those consideration are partly reproduced here: - Reverting the PR doesn't seem very minimal/trivial, and carries risks of its own. - Rename to a less-common but aim-to-stabilization name is itself not safe nor convenient, because (1) that risks introducing new regressions (i.e. ambiguity against the new name), and (2) lang would have to FCP the new name hastily for the mitigation to land timely and have a chance to be backported. This also makes the path towards stabilization annoying. - Rename the attribute to a rustc attribute, which will be perma-unstable and does not cause new ambiguities in stable code. - This alleviates the time pressure to address *this* regression, or for lang to have to rush an FCP for some new name that can still break user code. - This avoids backing out a whole implementation. ### Review advice This PR is best reviewed commit-by-commit. - Commit 1 adds a test `tests/ui/attributes/fn-align-nameres-ambiguity-143834.rs` which demonstrates the current name resolution regression re. `align`. This test fails against current master. - Commit 2 carries out the renames and test reblesses. Notably, commit 2 will cause `tests/ui/attributes/fn-align-nameres-ambiguity-143834.rs` to change from fail (nameres regression) to pass. This PR, if the approach still seems acceptable, will need a beta-backport to address the beta regression.

Mitigate `#[align]` name resolution ambiguity regression with a rename Mitigates beta regression rust-lang/rust#143834 after a beta backport. ### Background on the beta regression The name resolution regression arises due to rust-lang/rust#142507 adding a new feature-gated built-in attribute named `#[align]`. However, unfortunately even [introducing new feature-gated unstable built-in attributes can break user code](https://www.github.com/rust-lang/rust/issues/134963) such as ```rs macro_rules! align { () => { /* .. */ }; } pub(crate) use align; // `use` here becomes ambiguous ``` ### Mitigation approach This PR renames `#[align]` to `#[rustc_align]` to mitigate the beta regression by: 1. Undoing the introduction of a new built-in attribute with a common name, i.e. `#[align]`. 2. Renaming `#[align]` to `#[rustc_align]`. The renamed attribute being `rustc_align` will not introduce new stable breakages, as attributes beginning with `rustc` are reserved and perma-unstable. This does mean existing nightly code using `fn_align` feature will additionally need to specify `#![feature(rustc_attrs)]`. This PR is very much a short-term mitigation to alleviate time pressure from having to fully fix the current limitation of inevitable name resolution regressions that would arise from adding any built-in attributes. Long-term solutions are discussed in [#t-lang > namespacing macro attrs to reduce conflicts with new adds](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/namespacing.20macro.20attrs.20to.20reduce.20conflicts.20with.20new.20adds/with/529249622). ### Alternative mitigation options [Various mitigation options were considered during the compiler triage meeting](rust-lang/rust#143834 (comment)), and those consideration are partly reproduced here: - Reverting the PR doesn't seem very minimal/trivial, and carries risks of its own. - Rename to a less-common but aim-to-stabilization name is itself not safe nor convenient, because (1) that risks introducing new regressions (i.e. ambiguity against the new name), and (2) lang would have to FCP the new name hastily for the mitigation to land timely and have a chance to be backported. This also makes the path towards stabilization annoying. - Rename the attribute to a rustc attribute, which will be perma-unstable and does not cause new ambiguities in stable code. - This alleviates the time pressure to address *this* regression, or for lang to have to rush an FCP for some new name that can still break user code. - This avoids backing out a whole implementation. ### Review advice This PR is best reviewed commit-by-commit. - Commit 1 adds a test `tests/ui/attributes/fn-align-nameres-ambiguity-143834.rs` which demonstrates the current name resolution regression re. `align`. This test fails against current master. - Commit 2 carries out the renames and test reblesses. Notably, commit 2 will cause `tests/ui/attributes/fn-align-nameres-ambiguity-143834.rs` to change from fail (nameres regression) to pass. This PR, if the approach still seems acceptable, will need a beta-backport to address the beta regression.

rustbot added A-attributes T-compiler labels Jun 14, 2025

This comment has been minimized.

Sign in to view

folkertdev force-pushed the fn-align-align-attribute branch from 3d85cf8 to 8769e96 Compare June 14, 2025 15:24

This comment has been minimized.

Sign in to view

folkertdev force-pushed the fn-align-align-attribute branch from 8769e96 to 92fa35d Compare June 14, 2025 16:13

folkertdev commented Jun 15, 2025

View reviewed changes

compiler/rustc_passes/src/errors.rs Show resolved Hide resolved

compiler/rustc_attr_parsing/src/attributes/repr.rs Show resolved Hide resolved

rustbot assigned jdonszelmann Jun 15, 2025

folkertdev marked this pull request as ready for review June 15, 2025 19:29

rustbot added the S-waiting-on-review label Jun 15, 2025

jdonszelmann mentioned this pull request Jun 15, 2025

Tracking issue: Attribute refactor #131229

Open

9 tasks

jdonszelmann requested changes Jun 15, 2025

View reviewed changes

rustbot added S-waiting-on-author and removed S-waiting-on-review labels Jun 15, 2025

folkertdev force-pushed the fn-align-align-attribute branch from 92fa35d to 61e20fa Compare June 16, 2025 11:24

folkertdev force-pushed the fn-align-align-attribute branch from 61e20fa to ba3c409 Compare June 18, 2025 09:50

This comment has been minimized.

Sign in to view

add #[align] attribute

1fdf2b5

Right now it's used for functions with `fn_align`, in the future it will get more uses (statics, struct fields, etc.)

folkertdev force-pushed the fn-align-align-attribute branch from ba3c409 to 1fdf2b5 Compare June 18, 2025 10:37

bors added S-waiting-on-bors and removed S-waiting-on-author labels Jun 18, 2025

tgross35 mentioned this pull request Jun 19, 2025

Rollup of 7 pull requests #142697

Merged

bors merged commit 07932ad into rust-lang:master Jun 19, 2025
10 checks passed

rustbot added this to the 1.89.0 milestone Jun 19, 2025

folkertdev mentioned this pull request Jun 19, 2025

correct template for #[align] attribute #142715

Merged

folkertdev mentioned this pull request Jul 12, 2025

Regression: align is ambiguous #143834

Open

rustbot added the relnotes label Jul 14, 2025

rustbot mentioned this pull request Jul 14, 2025

Tracking issue for release notes of #142507: use #[align] attribute for fn_align #143923

Closed

jieyouxu mentioned this pull request Jul 14, 2025

warn on align on fields to avoid breaking changes #143868

Merged

jieyouxu removed the relnotes label Jul 17, 2025

jieyouxu mentioned this pull request Jul 17, 2025

Mitigate #[align] name resolution ambiguity regression with a rename #144080

Merged

use #[align] attribute for fn_align #142507

use #[align] attribute for fn_align #142507

Conversation

folkertdev commented Jun 14, 2025

Uh oh!

This comment has been minimized.

This comment has been minimized.

folkertdev commented Jun 15, 2025

Uh oh!

traviscross commented Jun 15, 2025

Uh oh!

folkertdev left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

rustbot commented Jun 15, 2025

Uh oh!

jdonszelmann commented Jun 15, 2025

Uh oh!

Uh oh!

jdonszelmann Jun 15, 2025

Choose a reason for hiding this comment

Uh oh!

jdonszelmann Jun 15, 2025

Choose a reason for hiding this comment

Uh oh!

folkertdev Jun 16, 2025

Choose a reason for hiding this comment

Uh oh!

jdonszelmann Jun 16, 2025

Choose a reason for hiding this comment

Uh oh!

folkertdev Jun 16, 2025

Choose a reason for hiding this comment

Uh oh!

jdonszelmann Jun 16, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jdonszelmann Jun 15, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

bors commented Jun 16, 2025

Uh oh!

jdonszelmann commented Jun 18, 2025

Uh oh!

This comment has been minimized.

jdonszelmann commented Jun 18, 2025

Uh oh!

jdonszelmann commented Jun 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bors commented Jun 18, 2025

Uh oh!

Uh oh!

apiraino commented Jul 14, 2025

Uh oh!

jieyouxu commented Jul 17, 2025

Uh oh!

use `#[align]` attribute for `fn_align` #142507

use `#[align]` attribute for `fn_align` #142507

jdonszelmann commented Jun 18, 2025 •

edited

Loading