Rename fail! to panic!

https://github.com/rust-lang/rfcs/pull/221

The current terminology of "task failure" often causes problems when
writing or speaking about code. You often want to talk about the
possibility of an operation that returns a Result "failing", but cannot
because of the ambiguity with task failure. Instead, you have to speak
of "the failing case" or "when the operation does not succeed" or other
circumlocutions.

Likewise, we use a "Failure" header in rustdoc to describe when
operations may fail the task, but it would often be helpful to separate
out a section describing the "Err-producing" case.

We have been steadily moving away from task failure and toward Result as
an error-handling mechanism, so we should optimize our terminology
accordingly: Result-producing functions should be easy to describe.

To update your code, rename any call to `fail!` to `panic!` instead.
Assuming you have not created your own macro named `panic!`, this
will work on UNIX based systems:

    grep -lZR 'fail!' . | xargs -0 -l sed -i -e 's/fail!/panic!/g'

You can of course also do this by hand.

[breaking-change]

3 files changed, 5 insertions, 5 deletions

diff --git a/src/libstd/rt/backtrace.rs b/src/libstd/rt/backtrace.rs
index e05e533be56..5bd39277275 100644
--- a/src/libstd/rt/backtrace.rs
+++ b/src/libstd/rt/backtrace.rs
@@ -8,7 +8,7 @@
 // option. This file may not be copied, modified, or distributed
 // except according to those terms.
 
-//! Simple backtrace functionality (to print on failure)
+//! Simple backtrace functionality (to print on panic)
 
 #![allow(non_camel_case_types)]
 
@@ -265,7 +265,7 @@ mod imp {
 
         // while it doesn't requires lock for work as everything is
         // local, it still displays much nicer backtraces when a
-        // couple of tasks fail simultaneously
+        // couple of tasks panic simultaneously
         static LOCK: StaticNativeMutex = NATIVE_MUTEX_INIT;
         let _g = unsafe { LOCK.lock() };
 
@@ -327,7 +327,7 @@ mod imp {
             // FindEnclosingFunction on non-osx platforms. In doing so, we get a
             // slightly more accurate stack trace in the process.
             //
-            // This is often because failure involves the last instruction of a
+            // This is often because panic involves the last instruction of a
             // function being "call std::rt::begin_unwind", with no ret
             // instructions after it. This means that the return instruction
             // pointer points *outside* of the calling function, and by
diff --git a/src/libstd/rt/mod.rs b/src/libstd/rt/mod.rs
index a91c6c572e6..e36d4ce8d4b 100644
--- a/src/libstd/rt/mod.rs
+++ b/src/libstd/rt/mod.rs
@@ -67,7 +67,7 @@ pub use rustrt::{task, local, mutex, exclusive, stack, args, rtio, thread};
 pub use rustrt::{Stdio, Stdout, Stderr, begin_unwind, begin_unwind_fmt};
 pub use rustrt::{bookkeeping, at_exit, unwind, DEFAULT_ERROR_CODE, Runtime};
 
-// Simple backtrace functionality (to print on failure)
+// Simple backtrace functionality (to print on panic)
 pub mod backtrace;
 
 // Just stuff
diff --git a/src/libstd/rt/util.rs b/src/libstd/rt/util.rs
index ec301369804..56f2dbf667a 100644
--- a/src/libstd/rt/util.rs
+++ b/src/libstd/rt/util.rs
@@ -62,7 +62,7 @@ pub fn default_sched_threads() -> uint {
             let opt_n: Option<uint> = FromStr::from_str(nstr.as_slice());
             match opt_n {
                 Some(n) if n > 0 => n,
-                _ => fail!("`RUST_THREADS` is `{}`, should be a positive integer", nstr)
+                _ => panic!("`RUST_THREADS` is `{}`, should be a positive integer", nstr)
             }
         }
         None => {