Missed optimization: destructor of variable needlessly called before `unreachable_unchecked`

Here is a godbolt link demonstrating the issue: https://godbolt.org/z/3GvY6938x

Pasted here for posterity:

pub enum MyEnum {
  V1(u32),
  V2(u32),
  V3(String),
}

fn unsafe_cast_v1(v: MyEnum) -> u32 {
  match v {
    MyEnum::V1(v) => v,
    MyEnum::V2(v) => v,
    // The destructor of the string is called, even though `unreachable` immediately follows
    MyEnum::V3(_) => unsafe { std::hint::unreachable_unchecked() },
  }
}

fn unsafe_cast_v2(v: MyEnum) -> u32 {
  match v {
    MyEnum::V1(v) => v,
    MyEnum::V2(v) => v,
    // The destructor of the string is not called
    MyEnum::V3(_s) => unsafe { std::hint::unreachable_unchecked() },
  }
}

The only difference between these two code samples is that I have given the string associated data a name "_s" in the second example. My intuition tells me this causes its destructor to be called after the unreachable_unchecked, which is pruned because it is after !. The _ variable's destructor is called immediately, before calling unreachable_unchecked, so it is not pruned.

unreachable_unchecked is not just -> !, it can be assumed to never be reached. So we should be able to prune all code which happens unconditionally before it, not just after it.

Start with the Rust code reproducer in the issue and inspect its generated output on the linked Godbolt example. Trace how the compiler handles the match arm containing unreachable_unchecked and the associated String destructor; done means the unnecessary destructor call is absent while the demonstrated behavior remains correct.