Miri: Check that a ptr is aligned and inbounds already when evaluating *

[RalfJung]

This syncs Miri with what the Nomicon and the Reference say, and resolves rust-lang/miri#447.

Also this would not have worked without #62982 due to new cycles. ;)

r? @oli-obk

[RalfJung]

See rust-lang/miri#863 for what this does with the Miri test suite.

[RalfJung]

@mjbshaw I just realized that this PR as-is would break your CTFE version of offset_of!. I wrote this PR purely to make Miri better in catching UB (concretely, as a reaction to this discussion, I wanted to align what Miri checks with what the Nomicon has said all along), but it turns out that this breaks your macro.

I am not sure what to do about this. On the one hand this makes this PR a breaking change, on the other hand the unsafe CTFE code that it breaks is UB and has been called out as such in the reference since forever, and on yet another hand I don't know of anything else you can currently do in CTFE to do offset_of!.

[mjbshaw]

Thanks for the heads up, @RalfJung.

On the one hand this makes this PR a breaking change

I don't really see it as a breaking change (at least not the kind that break's Rust's promises). I'm relying on UB, and I know that. UB can change (including break) at any time, which I'm okay with.

I've got mixed feelings here. On the one hand, I always knew this day would come and I can't blame you/anyone for making improvements like this. On the other hand, it sucks not being able to implement offset_of!. It's been a frustrating journey. I'll try to set aside some time though to work on a magic-macro-based implementation of offset_of!.

[oli-obk]

Could you use a Union to create an undef value of your type, take a reference to the field you want, make it a pointer, subtract that from the base pointer? Undef values are pretty well defined in miri

[RalfJung]

use a Union to create an undef value of your type

That only works for Copy types, or you have to use MaybeUninit.

[mjbshaw]

@oli-obk No. It's not possible to use a real object at all because Miri won't let you. Doing this requires:

• #![feature(const_raw_ptr_deref)] because of the expression &(*base).field.
• #![feature(const_raw_ptr_to_usize_cast)] to case the pointers to usize (so you can subtract them).
• Transmuting the *const MaybeUninit<T> to *const T since MaybeUninit::as_ptr() is non-const.

But even with all of that, Miri won't let you use the offset value.

[RalfJung]

Why doesn't the error say what the actual problem is...?

error: any use of this value will cause an error
     | 
    ::: <source>:13:1
     |
13   | / pub const OFFSET: usize = {
14   | |     let uninit = std::mem::MaybeUninit::<Struct>::uninit();
15   | |     let base_ptr: *const Struct = unsafe { TransmuteHack { from: &uninit }.to };
16   | |     let field_ptr = unsafe { &(*base_ptr).field as *const _ };
17   | |     let offset = unsafe { (field_ptr as usize).wrapping_sub(base_ptr as usize) };
18   | |     offset
19   | | };
     | |__-
     |
     = note: `#[deny(const_err)]` on by default

My guess is that wrapping_sub errors, the CTFE engine is not able to subtract pointers from each other. And once #62946 lands, actually the field_ptr as usize will already fail as it will try to get the raw bits of a pointer, which is not possible in CTFE.

Miri won't let you

Nit: Miri-the-tool has no issue with any of this. The problem here is the variant of the Miri engine used by CTFE.

[oli-obk]

Let's make wrapping_offset_from const fn. there's no reason it isn't.

Also yea, what's up with that horrible diagnostic

[RalfJung]

Let's make wrapping_offset_from const fn. there's no reason it isn't.

Uh, implementing this in general requires ptr-to-int casts... CTFE can only do this for pointers to the same object.

[oli-obk]

Sure, but that's fine imo. Casting raw pointers to usize will error for non-integer values, so calling wrapping_offset_from will error for pointers into distinct allocations. Or we just support offset_from which is unsafe and states

Both the starting and other pointer must be either in bounds or one byte past the end of the same allocated object.

[RalfJung]

But then I don't see how this helps...
Which implementation of offset_of! is helped by an integer-only wrapping_offset_from?

[oli-obk]

Why integer-only?. wrapping_offset_from using ptr to int casts is an implementation detail. We can add an intrinsic for it.

[RalfJung]

So you want to have a wrapping_offset_from that, despite being a safe function, fails for some inputs?

This is an "unconst" function. We should likely not allow calling it outside unsafe blocks in const context.

[oli-obk]

Oops, sorry, I meant offset_from. We don't need the wrapping version

[RalfJung]

That I guess we could do. It would have to become an intrinsic or so I suppose.