auto merge of #11283 : brson/rust/doublefailure, r=alexcrichton
Previously this was an `rtabort!`, indicating a runtime bug. Promote this to a more intentional abort and print a (slightly) more informative error message. Can't test this sense our test suite can't handle an abort exit. I consider this to close #910, and that we should open another issue about implementing less conservative semantics here.
This commit is contained in:
commit
239fb1f6ee
|
@ -3605,10 +3605,8 @@ 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.
|
||||
occurring from within this destructor results in *hard* failure.
|
||||
A hard failure currently results in the process aborting.
|
||||
|
||||
A task in the *dead* state cannot transition to other states; it exists
|
||||
only to have its termination status inspected by other tasks, and/or to await
|
||||
|
|
|
@ -354,7 +354,13 @@ pub fn begin_unwind<M: Any + Send>(msg: M, file: &'static str, line: uint) -> !
|
|||
}
|
||||
|
||||
if (*task).unwinder.unwinding {
|
||||
rtabort!("unwinding again");
|
||||
// If a task fails while it's already unwinding then we
|
||||
// have limited options. Currently our preference is to
|
||||
// just abort. In the future we may consider resuming
|
||||
// unwinding or otherwise exiting the task cleanly.
|
||||
rterrln!("task failed during unwinding (double-failure - total drag!)")
|
||||
rterrln!("rust must abort now. so sorry.");
|
||||
intrinsics::abort();
|
||||
}
|
||||
}
|
||||
|
||||
|
|
Loading…
Reference in New Issue