Validity of ManuallyDrop, or: ManuallyDrop<Box<_>> is strange

[RalfJung]

The ManuallyDrop docs say

ManuallyDrop is subject to the same layout optimizations as T. As a consequence, it has no effect on the assumptions that the compiler makes about its contents.

In particular, this means that a ManuallyDrop<Box<T>> must not dangle. But that means that after calling drop on a ManuallDrop<Box<T>>, that value violates the validity invariant and must not be used or passed around any more! I don't think that is the behavior we want.

We want ManuallyDrop to preserve niches, so we cannot really relax what it says about validity. But what we could relax is validity of Box -- we could say that validity is purely about the pointer value itself (it must be non-NULL and properly aligned). We could specify that the "dereferencability" only comes in through the aliasing model, and we could make that model stop looking into ManuallyDrop.

[theemathas]

Of note, ManuallyDrop<&mut T> and ManuallyDrop<&T> have similar behavior, although it's harder to accidentally run into. For example, the Miri says the following code has UB.

use std::mem::{ManuallyDrop, transmute};

fn main() {
    let x = Box::new(123);
    let y: &i32 = unsafe { transmute(&*x) };
    let mut z = ManuallyDrop::new(y);
    // Removing the following line does not affect the behavior
    unsafe { ManuallyDrop::drop(&mut z); }
    drop(x);
    let _moved = z;
}

[RalfJung]

Yeah, but it's less strange there since dropping &mut T is a NOP anway. So this issue focuses on ManuallyDrop<Box<T>>; &mut is just in it for consistency reasons.