about summary refs log tree commit diff
path: root/compiler/rustc_data_structures/src/binary_search_util
diff options
context:
space:
mode:
authorbors <bors@rust-lang.org>2024-05-29 11:57:13 +0000
committerbors <bors@rust-lang.org>2024-05-29 11:57:13 +0000
commitf2e1a3a80ae54734e1a3d306f31c2caebb05de9b (patch)
treed2c0f2cc38fec93e1f792592bd48c2bd968c69da /compiler/rustc_data_structures/src/binary_search_util
parent4cf5723dbe471ef0a32857b968b91498551f5e38 (diff)
parent37aeb75eb6c68dfee49e9ecdbd0c46e137b28bc7 (diff)
downloadrust-f2e1a3a80ae54734e1a3d306f31c2caebb05de9b.tar.gz
rust-f2e1a3a80ae54734e1a3d306f31c2caebb05de9b.zip
Auto merge of #125360 - RalfJung:packed-field-reorder, r=fmease
don't inhibit random field reordering on repr(packed(1))

`inhibit_struct_field_reordering_opt` being false means we exclude this type from random field shuffling. However, `packed(1)` types can still be shuffled! The logic was added in https://github.com/rust-lang/rust/pull/48528 since it's pointless to reorder fields in packed(1) types (there's no padding that could be saved) -- but that shouldn't inhibit `-Zrandomize-layout` (which did not exist at the time).

We could add an optimization elsewhere to not bother sorting the fields for `repr(packed)` types, but I don't think that's worth the effort.

This *does* change the behavior in that we may now reorder fields of `packed(1)` structs (e.g. if there are niches, we'll try to move them to the start/end, according to `NicheBias`).  We were always allowed to do that but so far we didn't. Quoting the [reference](https://doc.rust-lang.org/reference/type-layout.html):

> On their own, align and packed do not provide guarantees about the order of fields in the layout of a struct or the layout of an enum variant, although they may be combined with representations (such as C) which do provide such guarantees.
Diffstat (limited to 'compiler/rustc_data_structures/src/binary_search_util')
0 files changed, 0 insertions, 0 deletions