You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Accessing DST field of packed struct calculates the wrong field address #80925
It was actually a bug in the codegen backend, introduced when support for packed(N) was added -- the existing code has logic that assumed "if it is packed then alignment is 1", and that was never re-visited.
Ah, scratch that -- there was a different related bug (the size_of_val / align_of_val computation for packed structs with dyn Trait tail was wrong), caused by what I said above.
This here was caused by the codegen backend just never considering packed types when computing the offset of the unsized field. Almost always this happened to work since the unsized field is a slice/str and so its alignment (and therefore its offset) is dynamically known, but when dyn trait tails are involved this starts to go wrong.
Activity
mahkoh commentedon Feb 10, 2021
The labels are incorrect. Neither does this require nightly, nor is it related to const-eval. This is I-unsound on stable.
rustbot commentedon Feb 14, 2021
rustbot commentedon Feb 14, 2021
apiraino commentedon Feb 17, 2021
Assigning
P-mediumas discussed as part of the Prioritization Working Group procedure and removingI-prioritize.apiraino commentedon Feb 17, 2021
@rustbot label -I-prioritize +P-medium
nikomatsakis commentedon Nov 30, 2022
@rustbot labels -T-types
Discussed in types team on-site -- we think this is a MIR building bug, in any case, not part of T-types.
Throwing hot 🥔 back to compiler team.
RalfJung commentedon Dec 13, 2023
It was actually a bug in the codegen backend, introduced when support for
packed(N)was added -- the existing code has logic that assumed "if it is packed then alignment is 1", and that was never re-visited.RalfJung commentedon Dec 13, 2023
Ah, scratch that -- there was a different related bug (the size_of_val / align_of_val computation for packed structs with
dyn Traittail was wrong), caused by what I said above.This here was caused by the codegen backend just never considering packed types when computing the offset of the unsized field. Almost always this happened to work since the unsized field is a slice/str and so its alignment (and therefore its offset) is dynamically known, but when dyn trait tails are involved this starts to go wrong.
This got fixed by #118540; #118538 will add a test.
Rollup merge of rust-lang#118538 - RalfJung:size-of-val-comments, r=W…
Auto merge of rust-lang#118538 - RalfJung:size-of-val-comments, r=Waf…
Auto merge of rust-lang#118538 - RalfJung:size-of-val-comments, r=Waf…
Auto merge of #118538 - RalfJung:size-of-val-comments, r=WaffleLapkin