Local variable deallocated out of order in the panic path?

[theemathas]

I'm not sure if this is a bug or not.

#![allow(unused)]

use std::fmt::Display;

struct Wrap<T: Display>(T);
impl<T: Display> Drop for Wrap<T> {
    fn drop(&mut self) {
        println!("{}", self.0);
    }
}

fn main() {
    let x;
    {
        let y = 1;
        x = Wrap(&y);
        panic!();
    }
}

In the above code, I expected that, conceptually, the memory for y is deallocated, then the destructor for x is ran, then the memory for x is deallocated. Therefore, I would expect the code to not compile, since the Drop impl would be accessing freed memory.

Instead, the code compiles and runs fine, panicking and printing 1. Miri does not detect any UB.

Note that, if the value inside y has a destructor, then the code doesn't compile, as expected.

Removing the panic causes the code to stop compiling, as expected. Replacing the panic with drop(x) causes the code to compile again.

I am unable to cause UB with this behavior, but I still find it extremely weird.

Possibly related to #128225

Meta

Reproducible on the playground with version 1.92.0-nightly (2025-10-18 6380899f32599ea25615)

[danielhenrymantilla]

Note that his behavior is what resulted in https://docs.rs/generativity's macro API being unsound:

Click here for an inline description and explanation of the problem

We want the following a and b instances to have distinct types, e.g., for [a, b] to be an illegal expression (that's the whole soundness model of generativity / branding lifetimes).

We can, generally, achieve that through the following:

// Invariant
type PhantomInv<'lt> = ::core::marker::PhantomData<&'lt mut &'lt ()>;

trait GetLt<'lt> {
    fn get_lt(&self) -> PhantomInv<'lt> { <_>::default() }
}
impl GetLt<'_> for () {}

// RPIT is surprisingly well-fit for this task: it is deemed to have drop glue as far as
// dropck is concerned (whilst not having any actual one such at runtime). It also happens
// to be invariant over `use<'_>`.
fn invariant_and_with_drop_glue(_: &()) -> impl /* use<'_> + */ GetLt<'_> {}

macro_rules! make_unique_lt {(as let $varname:ident) => (
    let local = ();
    let guard = invariant_and_with_drop_glue(&local);
    let $varname = guard.get_lt();
)}

make_unique_lt!(as let a);
make_unique_lt!(as let b);
[a, b]; // Error!

Indeed, if we expand, and make life-spans of locals more explicit with { … }, we got:

{
  let local_a = ();
  let guard_a = invariant_and_with_drop_glue(&local);
  let a = guard_a.get_lt();
  {
    let local_b = ();
    let guard_b = invariant_and_with_drop_glue(&local);
    let b = guard_b.get_lt();

    [a, b];
  } // drop(guard_b); drop(local_b);
} // drop(guard_a); drop(local_a);

And consider: what is the lifetime inside the type of a and b respectively?

• since it borrows a local, the lifetime of the borrow cannot span beyond the life-span of that local => upper-bound.
  • Notably, here, the lifetime inside of b cannot span over drop(local_b).
• since the guard itself has drop glue, it "uses"/"activates" the lifetime in its (opaque) type when it gets dropped, so that lifetime needs to span beyond that point => lower-bound.
  • Notably, here, the lifetime inside of a must span beyond drop(guard_a).

Hence why there will "always" be a lifetime mismatch between the two bindings, and why the macro works.

But this very issue makes it so, if after the [a, b], there is an unwind code path, then, as per the rules observed in this issue (that the drop_in_place() calls of locals, the ones which both may invalidate borrows to the dropped, but also require a borrow inside of the droppee to have some lower-bound (to be valid during the drop point)), we get:

{
  let local_a = ();
  let guard_a = invariant_and_with_drop_glue(&local);
  let a = guard_a.get_lt();
  {
    let local_b = ();
    let guard_b = invariant_and_with_drop_glue(&local);
    let b = guard_b.get_lt();

    [a, b];

    // `drop_in_places()` hoisted here:
    (&raw mut guard_b).drop_in_place()
    (&raw mut guard_a).drop_in_place()
    unwind
  } // discard!(guard_b); discard!(local_b);
} // discard!(guard_a); discard!(local_a);

• (I am calling discard! the StorageDeads in MIR.)

And now, in our previous reasoning, the requirement for the lifetime inside of a to be strictly bigger than the one inside of b holds no more:

• the lifetime inside of a needs to at least span until the (&raw mut guard_a).drop_in_place(), since that is the last usage/"activation" of that lifetime.
• the lifetime inside of b still needs to be lesser than the discard!(local_b) point.

This is now solvable/satisfiable/there exists a choice of lifetime which satisfies all requirements (one which would end right after guard_a is dropped in place, but before the unwinding/discarding of the locals takes place).

• Issue: Duplicate brands with dead-code drop calls CAD97/generativity#15

  • Check out @ArhanChaudhary's post on this whole topic: https://arhan.sh/blog/the-generativity-pattern-in-rust/

• A fix: https://github.com/CAD97/generativity/pulls/16.

  • Now that the problem is better understood, it turns out there is a simpler fix than what that PR showcased: for the local borrowee to itself also have drop-glue. This shall lead to a (&raw mut local_b).drop_in_place() happening before the (&raw mut guard_a).drop_in_place(), that is, re-introducing the strict inequality property between the lifetime inside of b and that inside of a:

      // RPIT is surprisingly well-fit for this task!
    + fn drop_glue() -> impl Sized {}
      fn invariant_and_with_drop_glue(_: &impl Sized) -> impl GetLt<'_> {}
    
      macro_rules! make_unique_lt {(as let $varname:ident) => (
    -     let local = ();
    +     let local = drop_glue();
          let guard = invariant_and_with_drop_glue(&local);
          let $varname = guard.get_lt();
      )}
    
      …
    
    
          [a, b];
      
          // `drop_in_places()` hoisted here:
          (&raw mut guard_b).drop_in_place()
    +     (&raw mut local_b).drop_in_place(); // lifetime in b must end before this: error! 🙌
    
          (&raw mut guard_a).drop_in_place() // lifetime in a must include this
          unwind
        } // discard!(guard_b); discard!(local_b);
      } // discard!(guard_a); discard!(local_a);i

[tmiasko]

Yes, variables are deallocated out of order in the panic path (except in coroutines):

rust/compiler/rustc_mir_build/src/builder/scope.rs

Lines 258 to 268 in 1d23d06

	/// Whether there's anything to do for the cleanup path, that is,
	/// when unwinding through this scope. This includes destructors,
	/// but not StorageDead statements, which don't get emitted at all
	/// for unwinding, for several reasons:
	/// * clang doesn't emit llvm.lifetime.end for C++ unwinding
	/// * LLVM's memory dependency analysis can't handle it atm
	/// * polluting the cleanup MIR with StorageDead creates
	/// landing pads even though there's no actual destructors
	/// * freeing up stack space has no effect during unwinding
	/// Note that for coroutines we do emit StorageDeads, for the
	/// use of optimizations in the MIR coroutine transform.

[traviscross]

We talked about this in the lang call today. We knew why things were this way -- @nikomatsakis in particular described the history -- but we agreed that this is a bug.

We invite someone to create a PR to fix this, to crater it, to analyze the crater results and, as appropriate, to take other next steps such as to make PRs to affected projects, craft an appropriate FCW and propose that to us, and, eventually, to write the stabilization report for the breaking change and update the Reference, nominate the PR for us, and propose it to us for stabilization.

If you're interested in doing this, please reach out so we can find a lang champion to help with guiding this through the process.