RFC: Add an attribute for raising the alignment of various items #3806

Jules-Bertholet · 2025-05-01T22:19:24Z

Port C alignas to Rust.

text/3806-align-attr.md

hanna-kruppe · 2025-05-02T17:31:48Z

text/3806-align-attr.md

+In contrast to a `repr(align(…))` wrapper struct, an `align` annotation does *not*
+necessarily add extra padding to force the field to have a size that is a
+multiple of its alignment. (The size of the containing ADT must still be a
+multiple of its alignment; that hasn't changed.)


A field with #[align(N)] does raise the alignment of the containing ADT to be (at least) N, with all the potential padding that entails, right? I don't see how this can work otherwise, but I haven't seen it spelled out explicitly.

hanna-kruppe · 2025-05-02T17:37:44Z

text/3806-align-attr.md

+The `align` attribute is a new inert, built-in attribute that can be applied to
+ADT fields, `static` items, function items, and local variable declarations. The
+attribute accepts a single required parameter, which must be a power-of-2
+integer literal from 1 up to 2<sup>29</sup>. (This is the same as
+`#[repr(align(…))]`.)


The 2^29 limit is way too high. The consistency with #[repr(align(..))] is a good default but alignments larger than a page or two have never worked properly in local variables (rust-lang/rust#70143) and in statics (rust-lang/rust#70022, rust-lang/rust#70144). While there are some use cases for larger alignments on types (if they're heap allocated) and an error on putting such a type in a local or static is ugly, for this new attribute we could just avoid the problem from the start.

For a struct field, both GCC and clang supported _Alignas(N) for N ≤ 2²⁸ (268435456).

The bug with local variables (rust-lang/rust#70143) seems to have been fixed everywhere except Windows, and just waiting on someone to fix it there as well in LLVM. (And even on Windows where the issue is not fixed, the only effect is to break the stack overflow protection, bringing it down to the same level as many Tier 2 targets.)

So the only remaining issue is with statics, where it looks like a target-specific max alignment might be necessary. Once implemented, that solution can be used to address align as well.

Overall, I don't think any of this is sufficient motivation to impose a stricter maximum on #[align].

hanna-kruppe · 2025-05-02T17:40:31Z

text/3806-align-attr.md

+In Rust, a type’s size is always a multiple of its alignment. However, there are
+other languages that can interoperate with Rust, where this is not the case
+(WGSL, for example). It’s important for Rust to be able to represent such
+structures.


It's not clear to me how this would work while keeping Rust's "size is multiple of align" rule intact. I guess if it's about individual fields in a larger aggregate that maintains the rule in total? I don't know anything about WGSL so an example would be appreciated.

That’s exactly it. The WSGL example was taken from this comment on Internals: https://internals.rust-lang.org/t/pre-rfc-align-attribute/21004/20

Adding a worked example would indeed help readers of the RFC on this point.

hanna-kruppe · 2025-05-02T17:44:46Z

text/3806-align-attr.md

+after the `static`. For `static`s inside `unsafe extern` blocks, if the `static`
+does not meet the specified alignment, the behavior is undefined. (For
+misaligned `static` items declared inside old-style `extern` blocks, UB occurs
+only if the item is used.)


Why make this distinction? Making UB depend on surface syntax for essentially the same thing might UB detection (e.g., miri or rustc-inserted "UB checks") and exploitation more difficult, and since this is a new feature there's not even backwards compatibility concerns.

Making it UB even if not accessed enables more optimizations. For example, the compiler could hoist an access to the static outside of an if. And we can always relax this UB in the future, if it's not worth it

I don’t object to having UB if the item isn’t accessed. I just think it should be the same rules for unsafe extern {} and extern {} so later stages don’t have to carry around the distinction.

But old-style extern is safe, and safe code should not be able to cause UB.

There’s plenty of ways to cause UB with it today (many might be fixable). But we could also say “new extern {} features that can cause UB-by-wrong-declaration require unsafe extern {}”. Seems better to me than complicating Rust’s UB story for the future.

@hanna-kruppe is correct; it'd be better to simply require unsafe extern in order to use #[align(..)].

#[align] isn't special. The UB that can result if an extern static item specifies an incorrect alignment, is the same as the UB if such an item specifies an incorrect type. So restricting this feature to edition ≥2024 would not accomplish anything.

There’s plenty of ways to cause UB with it today (many might be fixable).

AFAIK, all should be fixable.

So restricting this feature to edition ≥2024 would not accomplish anything.

unsafe extern can be used in any edition.

Restricting to unsafe extern, then.

kpreid · 2025-05-02T22:53:32Z

text/3806-align-attr.md

+## On function items
+
+On function items, `#[align(…)]` sets the alignment of the function’s code. This
+replaces `#[repr(align(…))]` on function items from `#![feature(fn_align)]`.


Suggested change

replaces `#[repr(align(…))]` on function items from `#![feature(fn_align)]`.

replaces `#[repr(align(…))]` on function items from `#![feature(fn_align)]`.

This does not change the alignment of the function item type or the corresponding function pointer type, only the machine code they refer to.

Jules-Bertholet force-pushed the align-attr branch from 75d8fc6 to f6f7686 Compare May 1, 2025 22:20

Add align_attr RFC

3a4f5ac

Jules-Bertholet force-pushed the align-attr branch from f6f7686 to 3a4f5ac Compare May 1, 2025 22:21

Jules-Bertholet mentioned this pull request May 1, 2025

Stabilize fn_align: #[repr(align(N))] on functions and -Zmin-function-alignment rust-lang/rust#140261

Open

This was referenced May 1, 2025

Rust unstable features needed for the kernel Rust-for-Linux/linux#2

Open

bindgen wanted features & bugfixes Rust-for-Linux/linux#353

Open

ehuss added the T-lang Relevant to the language team, which will review and decide on the RFC. label May 2, 2025

traviscross added I-lang-nominated Indicates that an issue has been nominated for prioritizing at the next lang team meeting. I-lang-radar Items that are on lang's radar and will need eventual work or consideration. labels May 2, 2025

kennytm reviewed May 2, 2025

View reviewed changes

text/3806-align-attr.md Show resolved Hide resolved

Jules-Bertholet force-pushed the align-attr branch from 800e69d to eca25f7 Compare May 2, 2025 14:05

Add more mixing packed and aligned to future possibilities

4badbc9

Jules-Bertholet force-pushed the align-attr branch from eca25f7 to 4badbc9 Compare May 2, 2025 14:07

hanna-kruppe reviewed May 2, 2025

View reviewed changes

kpreid reviewed May 2, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

RFC: Add an attribute for raising the alignment of various items #3806

RFC: Add an attribute for raising the alignment of various items #3806

Jules-Bertholet commented May 1, 2025 •

edited by rustbot

Loading

hanna-kruppe May 2, 2025

Jules-Bertholet May 2, 2025

hanna-kruppe May 2, 2025

kennytm May 3, 2025

Jules-Bertholet May 3, 2025

hanna-kruppe May 2, 2025

Jules-Bertholet May 2, 2025

traviscross May 3, 2025

hanna-kruppe May 2, 2025

Jules-Bertholet May 2, 2025

hanna-kruppe May 2, 2025

Jules-Bertholet May 2, 2025

hanna-kruppe May 2, 2025 •

edited

Loading

traviscross May 3, 2025

Jules-Bertholet May 3, 2025 •

edited

Loading

traviscross May 3, 2025

Jules-Bertholet May 3, 2025

kpreid May 2, 2025

	replaces `#[repr(align(…))]` on function items from `#![feature(fn_align)]`.
	replaces `#[repr(align(…))]` on function items from `#![feature(fn_align)]`.
	This does not change the alignment of the function item type or the corresponding function pointer type, only the machine code they refer to.

RFC: Add an attribute for raising the alignment of various items #3806

Are you sure you want to change the base?

RFC: Add an attribute for raising the alignment of various items #3806

Conversation

Jules-Bertholet commented May 1, 2025 • edited by rustbot Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hanna-kruppe May 2, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Jules-Bertholet May 3, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Jules-Bertholet commented May 1, 2025 •

edited by rustbot

Loading

hanna-kruppe May 2, 2025 •

edited

Loading

Jules-Bertholet May 3, 2025 •

edited

Loading