Accessing DST field of packed struct calculates the wrong field address

[mahkoh]

Execute with Miri:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=7e7d31feebbea4c3caceaccff1fa6bac

The problem is that

rust/compiler/rustc_codegen_ssa/src/mir/place.rs

Lines 181 to 182 in 6526e5c

	// Bump the unaligned offset up to the appropriate alignment
	let offset = round_up_const_value_to_alignment(bx, unaligned_offset, unsized_align);

and

rust/compiler/rustc_mir/src/interpret/place.rs

Line 413 in 6526e5c

(base.meta, offset.align_to(align))

do not take the reduced field alignment into account and calculate the offset as-if the standard alignment was in place.

[mahkoh]

The labels are incorrect. Neither does this require nightly, nor is it related to const-eval. This is I-unsound on stable.

[apiraino]

Assigning P-medium as discussed as part of the Prioritization Working Group procedure and removing I-prioritize.

[apiraino]

@rustbot label -I-prioritize +P-medium

[nikomatsakis]

@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]

we think this is a MIR building bug

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]

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.

This got fixed by #118540; #118538 will add a test.