miri: explain why we use static alignment in ref-to-place conversion

[RalfJung]

@eddyb @oli-obk do you think this makes sense? Or should we use the run-time alignment (align_of_val)? I am a bit worried about custom DSTs, but that affects way more areas of Miri so I'd ignore them for now.

r? @oli-obk

[oli-obk]

Since the run-time alignment is stricter than the static alignment, we should probably not throw it away. Won't miri fail to detect certain unaligned reads otherwise?

[RalfJung]

Well, the question is whether a read must be aligned up to the dynamic alignment or whether the static alignment is sufficient.

I don't think we'll want to execute arbitrary code here, once align_of_val becomes user-definable. That seems like a strong argument to me to say that only the static alignment is actually required.

Only requiring static alignment is also consistent with our LLVM codegen, I believe.

[oli-obk]

Oh, I misunderstood what was going on. I can't think of any reason the static alignment would ever not be sufficient. Manual alignment tricks basically need this to work anyway, so...

@bors r+ rollup

[bors]

📌 Commit b01f81b has been approved by oli-obk

[RalfJung]

I don't think you misunderstood -- this does mean Miri will miss cases where a read is aligned enough for the static alignment of a type, but not aligned enough for the run-time alignment of a type. But what I said above is essentially that we should not make such cases UB.

[oli-obk]

Yes, if we made that UB, then turning a *const u32 into a *const u8 and reading through that would be UB, which is probably something done in embedded when starting out with u32s for aligned registers.

[RalfJung]

Yes, if we made that UB, then turning a *const u32 into a *const u8 and reading through that would be UB

I have no idea what you are talking about... but no, it would not.

But with a type like

struct Foo<T: ?Sized> {
  a: u32,
  b: T
}

if we create a x: Foo<dyn Debug> from a Foo<u64>, the dynamic alignment required when reading x.a is 8, but currently we only require it to be 4. I am saying that is okay, i.e., it should NOT be UB to read x.a at alignment 4 even if the vtable says that there's a u64 in the b.

With x: Foo<u64>, reading x.a at alignment 4 is UB.

[oli-obk]

With x: Foo<u64>, reading x.a at alignment 4 is UB.

wait what? that seems to immediately contradict

it should NOT be UB to read x.a at alignment 4

[RalfJung]

No, where is the contradiction? With y: Foo<u64>, when evaluating the place y.a, we start by evaluating y which must have alignment 8 (based on the layout of Foo<u64>). Then we adjust to the field's offset, adjusting 8 to offset 0 remains at 8, so the access happens with alignment 8. (When evaluating a projection, we don't care about the alignment of the field's type! We only care about the alignment we already know, and the offset.)

But with Foo<dyn Debug>, to determine the alignment 8 we'd have to use align_of_val. I don't think we want to do that. Instead we use layout.align.abi, which for this type is 4.