Tracking issue for release notes of #122792: Stabilize `min_exhaustive_patterns`

[rustbot]

This issue tracks the release notes text for #122792.

• [x] Issue is nominated for the responsible team (and T-release nomination is removed).
• [ ] Proposed text is drafted by team responsible for underlying change.
• [ ] Issue is nominated for release team review of clarity for wider audience.
• [ ] Release team includes text in release notes/blog posts.

Release notes text:

The section title will be de-duplicated by the release team with other release notes issues. Prefer to use the standard titles from previous releases. More than one section can be included if needed.

# Language
- [Patterns matching empty types can now be omitted in common cases](https://github.com/rust-lang/rust/pull/122792)

Release blog section (if any, leave blank if no section is expected):

Empty patterns can now be omitted in common cases:

```rust
pub fn safe_unwrap<T>(x: Result<T, !>) -> T {
    let Ok(x) = x; // the `Err` case does not need to appear
    x
}

// TODO: other examples, maybe std's PoisonError?

This is particularly useful in combination with the never type !, but also works with other empty types such a variantless enum (enum Void {}).

For reasons related to uninitialized values and unsafe code, this behavior is not allowed if the empty type is accessed through a reference, pointer, or union field:

pub fn safe_unwrap_ref<T>(x: &Result<T, !>) -> &T {
    match x {
        Ok(x) => x,
        Err(never) => match *never {}, // this branch cannot be omitted because of the reference
    }
}

To avoid interfering with crates that wish to support several rust versions, these branches are not yet warned as "unreachable", despite the fact that they can be removed.

[Mark-Simulacrum]

This may or may not want to incorporate notes for https://github.com/rust-lang/rust/issues/129031.

[traviscross]

@Nadrieril: What do you think?

cc @rust-lang/lang

[Nadrieril]

Should I edit the OP? I'm not sure how this works.

[Mark-Simulacrum]

Yes. I've revised the release note section a bit to not reference the semi-internal name (min_exhaustive_patterns) which we try to stay away from in favor of something more user-facing.