Miri does not detect invalid uses of alchemy (std::ptr::from_raw_parts w/ invalid vtable pointer) about miri

[RalfJung]

Miri detects when the vtable does not match the trait given in the type. There's not a lot more that can be detected - Rust does not have typed memory so there is no sense in which "an object of type Gold" exists or "an object of type Lead" does not exist. Your code is no worse than code that does something like "&*(&Gold as *const Gold as *const Lead)". That kind of code is pretty common and should definitely be allowed (if the two types have sufficiently compatible layout). The same applies to your code.

[LunarLambda]

I thought Miri already tracks the "true type" of each pointed-to object/"alloc" for other purposes?

Also, I know ZST-transmutes are fine, but I don't see how creating a mismatched trait object is equivalent?

Unless you're suggesting that dispatching via the wrong vtable for the erased type is okay as long as an equivalent transmute between the two recipient types would be valid?

Or put another way, my code is the same as casting &Leas to &Gold and then that to &dyn Any? That seems like a pretty strong thing to allow, but I guess I don't have a counterargument, since the size and alignment fields in the vtable have to match, but that's also true for transmuting &T to &U in general.

[RalfJung]

I thought Miri already tracks the "true type" of each pointed-to object/"alloc" for other purposes?

There is no such thing as the "true type" of an object. In memory, there are just bytes. The bytes are a bit more fancy than you may be used to, but they are still fundamentally untyped.

[RalfJung]

Unless you're suggesting that dispatching via the wrong vtable for the erased type is okay as long as an equivalent transmute between the two recipient types would be valid?

Yes, that is a good way to put it -- that's what Miri currently implements. (Note that the wrong vtable still has to be for the same trait as the original vtable, otherwise Miri will immediately complain.) I don't think @rust-lang/opsem has made an official decision on this, but this seems most consistent with our general stance on memory being untyped.

Closing as not-a-bug.

[LunarLambda]

got it, thank you! very interesting.