Repository navigation
Aligned-in-packed restriction can be circumvented with generic parameters #80926
Description
Activity
I think this works as intended? Packed representation ignores field alignment requirements
Ah, apparently not:
error[E0588]: packed type cannot transitively contain a `#[repr(align)]` typeNot sure what the rationale is there
what the rationale is there
So please don't remove it
Do bear in mind that you are relying on what is explicitly been considered an unspecified behaviour. While this loophole existing does introduce some soft constraints for when the interaction between packed and align needs to be defined, it is not necessarily the case that Rust will be super hard-pressed to maintain the current behaviour.
Do bear in mind that you are relying on what is explicitly been considered an unspecified behaviour.
Nevertheless it is exactly the behavior documented in the reference if the sentence disallowing it were omitted.
I feel like we should just remove the aligned-in-packed check. There's probably already code out there relying on its current behavior via generics (even accidentally). And I don't think the behavior is particularly surprising either,
packedacts onaligntypes the same way it acts on all types -- it completely ignores their alignment.Having types that can be written with generics but not monomorphic is obviously inconsistent, and means the check can at best serve as a lint anyway. We had a similar situation with
repr(transparent)and that got fixed by also allowing the attribute on types where all fields are 1-ZST.I wonder what @rust-lang/lang thinks about this -- the original goal was to avoid having to decide either way for the interaction of packed and align. Different C implementations seem to behave differently: on MSVC,
__declspec(align(N))types are fully aligned even in a packed struct; in GCC__attribute__((aligned(N)))types behave like all other types in a packed struct. But now that we inadvertently already made a decision to behave like GCC, is it really worth keeping the restriction?Discussed at T-lang triage meeting.
- We think the restriction can be safely lifted, in the manner described by @RalfJung above.
- We would not object if the restriction were readded in the form of a best-effort lint. I.e., we do not see it as a downside if people are expected to explicitly add an
#[allow]in the cases where they are putting an aligned type in a field of a packed struct, so that casual readers of the code will know something funky is going on.
@rustbot label: -I-lang-nominated
- added a commit that references this issue
on Sep 14, 2026 - added a commit that references this issue
on Sep 21, 2026
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=596ca7ba423417b421439fa86cc57e9c
See also rust-lang/rfcs#3060
The effective layout seems to correspond to the layout used on non-MS platforms. This is quite useful to circumvent the restriction and I'll have to make use of it to interact with certain C apis as described in the RFC issue. So please don't remove it.