Failing destructors leak resources

[alexcrichton]

In this program, the local variable _a is leaked:

struct Foo;

impl Drop for Foo {
    fn drop(&mut self) { fail!(); }
}

fn main() {
    let _a = box 1;
    let _b = Foo;
}

[alexcrichton]

Nominating, I feel uncertain about our story of failing destructors.

[thehydroimpulse]

This was one of the motivations for the original algebraic effects systems (and the RFC I wrote). But that was a much bigger abstraction than merely fixing this scenario. I guess it was somewhat similar to C++'s nofail exception guarantee.

[brson]

I'm a little shocked that this problem still exists.

[brson]

P-high, not 1.0

So:

fn main() {
    let b = Bar;
    let f = Foo;
}

compiles down to:

define internal void @_ZN4main20hd8096a747d8d732eIaa4v0.0E() unnamed_addr #0 {
entry-block:
  %b = alloca %"struct.Bar<[]>"
  %f = alloca %"struct.Foo<[]>"
  %0 = getelementptr inbounds %"struct.Bar<[]>"* %b, i32 0, i32 0
  store i1 true, i1* %0
  %1 = getelementptr inbounds %"struct.Foo<[]>"* %f, i32 0, i32 0
  store i1 true, i1* %1
  call void @_ZN3Foo14glue_drop.114317h8e9a26d4f7ff5149E(%"struct.Foo<[]>"* %f)
  call void @_ZN3Bar14glue_drop.114517hb6d883694ad7fcd5E(%"struct.Bar<[]>"* %b)
  ret void
}

To me it looks like at least all but the last one should be Invoke instructions with a landing pad.

[nrc]

So the desired behaviour if we fail in a destructor is to return and execute any other destructors and then continue to fail? If that sounds right, this should just be a matter of adding landing pads for the dtor calls as @jakub- suggests, right? I assume that if one of the other destructors fails, then we will go down the double-fail path automatically?

[alexcrichton]

That's what I would expect at least! We don't support more than double-failure at the library level, so we can probably avoid any more nesting after the first landing pad.