Document subtleties of ManuallyDrop

[theemathas]

After seeing #130140 and #130141, I figured that ManuallyDrop needs documentation explaining its subtleties, hence this PR.

See also rust-lang/unsafe-code-guidelines#245

[rustbot]

r? @thomcc

rustbot has assigned @thomcc.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[Noratrieb]

@scottmcm what did you nominate this for? should this PR be blocked on that or is this about a sperate issue than adding documentation warning about what is a potentially dangerous pattern right now?

[WaffleLapkin]

cc @rust-lang/opsem

[WaffleLapkin]

some wording/style nitpicks

[scottmcm]

@Noratrieb I'd much rather just remove the subtleties so we don't have to document them :P

Dunno whether that's practical, though. I just don't want to do a bunch of ManuallyDrop -> MaybeUninit everywhere now, then undo it again shortly.

[CAD97]

The subtlety of “using the value after it's been [manually] dropped” continues to be annoying. The one for moving can and should be fixed, but the case of derives using the value after it's been dropped is a clear cut violation of the safety contract, unfortunately. (This is why unsafe postconditions on the caller are hard.)

The diff for patching move-based holes can be minimized by utilizing a temporary interim impl of ManuallyDrop on top of MaybeUninit, at the cost of niche optimizations. Then it should be just a matter of swapping out the import.

[theemathas]

The diff for patching move-based holes can be minimized by utilizing a temporary interim impl of ManuallyDrop on top of MaybeUninit, at the cost of niche optimizations. Then it should be just a matter of swapping out the import.

Such an impl is available in Yandros's maybe-dangling crate. Should this link be added to the PR?

[thomcc]

This looks fine to me, but I find it deeply unpleasant. I'll leave it open for the lang team nomination though.

[RalfJung]

Just saw this comment by @pnkfelix from the lang team meeting

We could also file a bug against Miri (if we are confident that Miri is the sole way to observe UB here, which I am not confident of currently).

A ManuallyDrop<Box> is marked as noalias in LLVM. This has to be reflected in Miri. The default aliasing model we use, Stacked Borrows, only supports noalias in combination with "dereferenceable at the moment of function invocation" (which is different from the LLVM dereferenceable attribute which means "dereferenceable for the entire duration of the function"). This means that when a Box value is moved, Stacked Borrows inevitably checks that it is dereferenceable, triggering UB if the Box was dropped already.

The upshot is that to make code like this not trigger Miri UB, we'd have to

• Either entirely remove the aliasing treatment of Box (at least those wrapped in ManuallyDrop), thus also missing real UB caused by the Box noalias attribute
• Or deprecate Stacked Borrows in favor of Tree Borrows

I don't think we should do either of these.

We could stop adding noalias to Box inside ManuallyDrop in codegen and in Miri -- that would basically be a partial implementation of MaybeDangling. Since ManuallyDrop is already a lang item, that shouldn't even be that hard.

[tmandry]

The outcome we discussed in the lang team meeting is that we should document this behavior for now, but also document that it is likely to change in the future once RFC 3336 (MaybeDangling) is implemented. I see that the PR already does this, so I think we can move forward with merging it.

@rustbot label -I-lang-nominated

[GoldsteinE]

I think documentation should clarify that this also applies to any types that directly contain Box<_>, like (Box<T>, u8) or struct Foo(Box<T>);.

I also believe that per current rules, calling ManuallyDrop::drop() on any type that directly contains Box<_> is insta-UB, even if you don’t move it afterwards. Technically, it doesn’t neccessarily count as producing an invalid value:

“Producing” a value happens any time a value is assigned to or read from a place, passed to a function/primitive operation or returned from a function/primitive operation.

but at least touching it in any way (like creating a reference) is certainly UB.

[CAD97]

If you don't name the place after calling ManuallyDrop::drop, everything is fine; the place isn't touched after that point. Because ManuallyDrop does not have any drop glue, it does not get a drop_in_place terminator at the end of scope, and thus the place is never "used" implicitly by the language, and no reference is created unless you create it yourself.

[theemathas]

I have reworded the text to clarify that the UB also applies to types containing Box.

I am pretty sure that calling ManuallyDrop::drop() on a type containing Box is not UB. rust-lang/unsafe-code-guidelines#245 only states that using the ManuallyDrop later is UB. If you believe that ManuallyDrop::drop() is insta-UB, then I would like a citation to prove otherwise.

Of note, Miri doesn't seem to complain anything if I create a reference to an already-dropped ManuallyDrop<Box<T>>. I believe this is because we are still undecided on whether the existence of a &T implies that the T must be valid.

[GoldsteinE]

Re-reading a reference, I don’t think I can prove that it’s insta-UB. This is certainly UB per reference though:

let mut x = ManuallyDrop::new(Box::new(42));
unsafe { ManuallyDrop::drop(&mut x); }
let _y = &x;

since it produces (by writing to a place) an invalid value. Reference takes a conservative stance and declares references to invalid values to be invalid:

A reference or Box that is dangling, misaligned, or points to an invalid value (in case of dynamically sized types, using the actual dynamic type of the pointee as determined by the metadata).

[theemathas]

From rust-lang/unsafe-code-guidelines#412:

Note that the Rust reference currently answers ["whether a reference requires the pointed-to data to be valid"] with "yes", but in my view this is mostly because we haven't yet figured out what exactly the weaker requirement is that we actually want to impose.

[GoldsteinE]

Yeah, I know. I still think that documentation should be coherent: if we document this as being unsound in reference, it should be also documented as being unsound in other places that deal with the same situation.

[theemathas]

I just found out that the nightly version of the reference now states:

A reference or Box<T> must be aligned, it cannot be dangling, and it must point to a valid value (in case of dynamically sized types, using the actual dynamic type of the pointee as determined by the metadata). Note that the last point (about pointing to a valid value) remains a subject of some debate.

[theemathas]

This PR is still labelled with S-waiting-for-team. Which team is it waiting on?

[traviscross]

@bors r=thomcc,traviscross rollup=always

[bors]

📌 Commit de2eba1 has been approved by thomcc,traviscross

It is now in the queue for this repository.