Tracking issue for release notes of #155750: Document that `ManuallyDrop`'s `Box` interaction has been fixed

[rustbot]

This issue tracks the release notes text for #155750.

cc @WaffleLapkin, @jhpratt -- original issue/PR authors and assignees for drafting text

See the forge.rust-lang.org chapter about release notes for an overview of how the release team makes use of these tracking issues.

Release notes text

This section should be edited to specify the correct category(s) for the change, with succinct description(s) of what changed. Some things worth considering:

• Does this need an additional compat notes section?
• Was this a libs stabilization that should have additional headers to list new APIs under Stabilized APIs and Const Stabilized APIs?

# Libraries
- [Document that `ManuallyDrop`'s `Box` interaction has been fixed](https://github.com/rust-lang/rust/pull/155750)

Tip

Use the previous releases for inspiration on how to write the release notes text and which categories to pick.

Release blog section

If this change is notable enough for inclusion in the blog post then this section should be edited to contain a draft for the blog post. Otherwise leave it empty.

# Fix to the `ManuallyDrop` and `Box` interaction

Prior to Rust 1.96.0, there was a bug in the Rust compiler, which made the following code undefined behavior:

```rust
let mut x = ManuallyDrop::new(Box::new(1));
unsafe { ManuallyDrop::drop(&mut x) }
let x = x; // UB!
```

This is because the compiler considers moving a `Box` that has been dropped (deallocated) undefined behavior, and `ManuallyDrop` used to propagate that, such that moving `ManuallyDrop<Box<_>>` where the box has been dropped would also be considered UB.

In Rust 1.96.0 we fixed this, so this code is no longer UB. In this release we have updated the `ManuallyDrop` documentation, providing a stable guarantee that this code will not be UB in the future as well. See [`ManuallyDrop` docs](TODO) and the [related RFC](https://rust-lang.github.io/rfcs/3336-maybe-dangling.html) for more information.

Note

If a blog post section is required the release-blog-post label should be added (@rustbot label +release-blog-post) to this issue as otherwise it may be missed by the release team.

[WaffleLapkin]

cc @RalfJung in case you think the blog post should be worded differently :)

[RalfJung]

I fixed one typo.

I am not sure if I agre with characterizing this as a "compiler bug", it was more of a "language bug".

[WaffleLapkin]

@RalfJung I'm not sure how to rephrase this to be honest. "language bug" sounds weird (even if more correct), because the language is not really a program...

[RalfJung]

Specifications can have bugs. Whether you consider a spec to be a program is a separate question but that wouldn't be unreasonable either.

A compiler bug to me means that the compiler did not behave as documented/specified.

[WaffleLapkin]

But there isn't really a formal specification of Rust, so it's not clear to me where the bug was fixed.

In a sense, this is an announcement that the compiler no longer considers UB a certain patterns of code, after we decided that the language shouldn't have UB there.

I agree that compiler bug doesn't describe what happened well, but I don't know how to succinctly describe this in a way that a rust user will understand...

[RalfJung]

There's no formal spec but there is a spec in the form of library docs and the Reference.