I'd say the main problem here is that drop_in_place isn't inlined. If it were, it would be optimized away.

#69715 tracks alternative MIR solution which is to track active enum variants during drop elaboration.

After taking a closer look, the reason it doesn't get inlined is that we explicitly mark it as noinline here:

Though argument promotion doesn't happen either, not sure why that is.

#69715 tracks alternative MIR solution which is to track active enum variants during drop elaboration.

It's aiming at enum variant which doesn't need drop. I'm not sure if it can also eliminate conditional de-allocation inside drop like drop(String::new()).

Though argument promotion doesn't happen either, not sure why that is.

Apparently because a bitcast is sitting before the load.

; not promoted
  %0 = bitcast i32** %_1 to {}**
  %1 = load {}*, {}** %0, align 8
; promoted
  %0 = load i32*, i32** %_1, align 8
  %1 = bitcast i32* %0 to {}*

#69715 tracks alternative MIR solution which is to track active enum variants during drop elaboration.

It's aiming at enum variant which doesn't need drop. I'm not sure if it can also eliminate conditional de-allocation inside drop like drop(String::new()).

The idea is to solve a data flow problem that answers which enum variants might reach a drop terminator. In the case here, we know that Option doesn't implement Drop, and that the only variant that might reach drop is None which doesn't contain anything that needs to be dropped either. Thus it would be valid to remove the drop terminator.

This is de-facto implemented as part of const validation which statically ensures that there are no live drops. Following const variant already compiles successfully (even though destructors cannot be evaluated at compile-time):

pub const fn foo() {
    let _var: Option<Box<i32>> = None;
    g();
}

pub const fn g() {}

we explicitly mark it as noinline here

Seems this issue has the same root cause as #46515.

And the LLVM issue of heavily inlining, mentioned in #41696, which let us mark drop in unwinding noinline, is still NOT fixed. https://bugs.llvm.org/show_bug.cgi?id=33072

The idea is to solve a data flow problem that answers which enum variants might reach a drop terminator.

My point is that the MIR approach cannot handle manual drop impl which conditional does nothing. This code cannot have drop eliminated without inlining.

pub fn foo(g: fn()) {
    let _var = String::new(); // This does not alloc.
    g();
}

bors also closing this issue in #95338 was unexpected, cc @nagisa @erikdesjardins.