Decide what to do when on task double-failure

[brson]

Currently there are no landing pads generated for resource destructors so they are leaky when they fail. We don't have the same tricky situation that C++ has with throwing destructors but I haven't thought through how it should work yet.

Edit: This issue has changed into what to do after a dtor fails during unwinding. The previous issue of dtor failure not working at all has been resolved.

[brson]

There's a failing test in run-fail/unwind-resource-fail.rs

[brson]

And another in run-fail/unwind-resource-fail2.rs

[brson]

The language reference is actually quite explicit about this:

"A task may transition to the failing state at any time, due to an un-trapped signal or the evaluation of a fail expression. Once failing, a task unwinds its stack and transitions to the dead state. Unwinding the stack of a task is done by the task itself, on its own control stack. If a value with a destructor is freed during unwinding, the code for the destructor is run, also on the task's control stack. Running the destructor code causes a temporary transition to a running state, and allows the destructor code to cause any subsequent state transitions. The original task of unwinding and failing thereby may suspend temporarily, and may involve (recursive) unwinding of the stack of a failed destructor. Nonetheless, the outermost unwinding activity will continue until the stack is unwound and the task transitions to the dead state. There is no way to “recover” from task failure. Once a task has temporarily suspended its unwinding in the failing state, failure occurring from within this destructor results in hard failure. The unwinding procedure of hard failure frees resources but does not execute destructors. The original (soft) failure is still resumed at the point where it was temporarily suspended. "

[graydon]

Yeah. The hard/soft thing has never been implemented, as far as I know, but I think it's the best we can do: retain correctness of our memory model and try to retain correctness of user code, but not at the cost of infinite-recursion. If their dtor itself fails, just unwind that sub-failure w/o the opportunity for sub-sub-failures.

[pnkfelix]

�It would be good to revise the title of this bug to reflect what the task is. (From the comments thus far, it sounds like the task is to implement the hard/sort failure unwindin protocol; but it might also be useful to clean up the docs here.)

[pnkfelix]

Not critical for 0.6; de-milestoning

[bblum]

confirmed again; current code that can crash is as follows:

struct Foo { x: ~int, }

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

fn main() {
    let _x = Foo { x: ~5, };
    fail!();
}

If my idea for an effect system goes through, we might make this sound again by simply requiring no failure in destructors, e.g. trait Drop { #[wont(Fail)] fn finalize(...); }.

[bblum]

nominating for well-defined milestone

[graydon]

there is language about this in the manual already in the task section, so I think it's well defined already. just not implemented. feature completeness issue.