add rustc_no_writable to mem::forget and structs it uses

[quiode]

This builds upon #155207 and is similar to #157202. It adds the #[rustc_no_writable] attribute to mem::forget and the MaybeDangling and ManuallyDrop. This makes a pattern found in the crate derive_more work again.

As the pattern itself is quite unclean, and I have not seen mem::forget to cause trouble before with implicit writes, I'm not sure how much sense it makes to add it to mem::forget. The test works unter Tree Borrows, but fails already for Stacked Borrows. Thus I would be happy for some guidance if the attribute makes sense here @RalfJung @JoJoDeveloping.

[rustbot]

miri is developed in its own repository. If possible, consider making this change to rust-lang/miri instead.

cc @rust-lang/miri

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
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

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: libs
• libs expanded to 12 candidates
• Random selection from Darksonn, JohnTitor, Mark-Simulacrum, clarfonthey, jhpratt

[quiode]

r? @RalfJung

[rustbot]

RalfJung is not on the review rotation at the moment.
They may take a while to respond.

[mejrs]

This makes a pattern found in the crate derive_more work again.

What does this mean? Make it pass on Miri? Does it make previously erroring code compile? Is it making something ub into not-ub?

[asquared31415]

Is there a reason that we want to bless this pattern with mem::forget specifically, as opposed to guiding people to "pre-forgetting" to avoid reborrowing a reference after creating a derived reference? The following replacement of transmute, for example, does not report UB under the same miri settings.

unsafe fn transmute<From, To>(from: From) -> To {
    let from = ManuallyDrop::new(from); // effectively already forgotten, but happens first, so no reborrow after the copy
    unsafe { mem::transmute_copy(&from) }
}

View changes since the review

[saethlin]

Adding a test case is not the same as blessing a code pattern. We should still tell people that it is a bad idea to write code like this.

[asquared31415]

Specifically adding the attribute to mem::forget was what I was considering "blessing" it, but the test case was the most obvious place I could think of to demonstrate the pattern. But if this attribute is mostly meant as "internally mitigate the real world effects" rather than a "this is fine actually", then it makes more sense.

[saethlin]

The only thing that should be taken as "this is fine actually" is documentation.

[JoJoDeveloping]

The attribute is part of an experiment by @RalfJung and me and @quiode to see if we can unlock more optimizations w/o breaking too much real-world code and that includes figuring out which places need this attribute (and if that is "too many"). Since this is all highly experimental, we have not yet thought about how much "intentionality" the attribute ought to convey. Currently we're using it for both, at some later point we will need to decide where the attribute is "intended" and where not (if we decide we want to keep it at all). So I hope we do not need to decide that now :)