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.

doc/rust.md

@@ -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

src/libstd/rt/unwind.rs

@@ -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();
             }
         }