about summary refs log tree commit diff
path: root/src/libstd/sync
diff options
context:
space:
mode:
authorSteve Klabnik <steve@steveklabnik.com>2014-10-09 15:17:22 -0400
committerSteve Klabnik <steve@steveklabnik.com>2014-10-29 11:43:07 -0400
commit7828c3dd2858d8f3a0448484d8093e22719dbda0 (patch)
tree2d2b106b02526219463d877d480782027ffe1f3f /src/libstd/sync
parent3bc545373df4c81ba223a8bece14cbc27eb85a4d (diff)
downloadrust-7828c3dd2858d8f3a0448484d8093e22719dbda0.tar.gz
rust-7828c3dd2858d8f3a0448484d8093e22719dbda0.zip
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]
Diffstat (limited to 'src/libstd/sync')
-rw-r--r--src/libstd/sync/future.rs18
-rw-r--r--src/libstd/sync/task_pool.rs6
2 files changed, 12 insertions, 12 deletions
diff --git a/src/libstd/sync/future.rs b/src/libstd/sync/future.rs
index 621c08fe7bc..36070509432 100644
--- a/src/libstd/sync/future.rs
+++ b/src/libstd/sync/future.rs
@@ -58,7 +58,7 @@ impl<A> Future<A> {
         let state = replace(&mut self.state, Evaluating);
         match state {
             Forced(v) => v,
-            _ => fail!( "Logic error." ),
+            _ => panic!( "Logic error." ),
         }
     }
 
@@ -70,10 +70,10 @@ impl<A> Future<A> {
         */
         match self.state {
             Forced(ref v) => return v,
-            Evaluating => fail!("Recursive forcing of future!"),
+            Evaluating => panic!("Recursive forcing of future!"),
             Pending(_) => {
                 match replace(&mut self.state, Evaluating) {
-                    Forced(_) | Evaluating => fail!("Logic error."),
+                    Forced(_) | Evaluating => panic!("Logic error."),
                     Pending(f) => {
                         self.state = Forced(f());
                         self.get_ref()
@@ -132,7 +132,7 @@ impl<A:Send> Future<A> {
         let (tx, rx) = channel();
 
         spawn(proc() {
-            // Don't fail if the other end has hung up
+            // Don't panic if the other end has hung up
             let _ = tx.send_opt(blk());
         });
 
@@ -193,8 +193,8 @@ mod test {
 
     #[test]
     #[should_fail]
-    fn test_futurefail() {
-        let mut f = Future::spawn(proc() fail!());
+    fn test_future_panic() {
+        let mut f = Future::spawn(proc() panic!());
         let _x: String = f.get();
     }
 
@@ -211,7 +211,7 @@ mod test {
     }
 
     #[test]
-    fn test_dropped_future_doesnt_fail() {
+    fn test_dropped_future_doesnt_panic() {
         struct Bomb(Sender<bool>);
 
         local_data_key!(LOCAL: Bomb)
@@ -224,13 +224,13 @@ mod test {
         }
 
         // Spawn a future, but drop it immediately. When we receive the result
-        // later on, we should never view the task as having failed.
+        // later on, we should never view the task as having panicked.
         let (tx, rx) = channel();
         drop(Future::spawn(proc() {
             LOCAL.replace(Some(Bomb(tx)));
         }));
 
-        // Make sure the future didn't fail the task.
+        // Make sure the future didn't panic the task.
         assert!(!rx.recv());
     }
 }
diff --git a/src/libstd/sync/task_pool.rs b/src/libstd/sync/task_pool.rs
index a00eeb1f938..d4a60fb5844 100644
--- a/src/libstd/sync/task_pool.rs
+++ b/src/libstd/sync/task_pool.rs
@@ -42,9 +42,9 @@ impl<T> TaskPool<T> {
     /// `init_fn_factory` returns a function which, given the index of the
     /// task, should return local data to be kept around in that task.
     ///
-    /// # Failure
+    /// # Panics
     ///
-    /// This function will fail if `n_tasks` is less than 1.
+    /// This function will panic if `n_tasks` is less than 1.
     pub fn new(n_tasks: uint,
                init_fn_factory: || -> proc(uint):Send -> T)
                -> TaskPool<T> {
@@ -96,7 +96,7 @@ fn test_task_pool() {
 
 #[test]
 #[should_fail]
-fn test_zero_tasks_failure() {
+fn test_zero_tasks_panic() {
     let f: || -> proc(uint):Send -> uint = || { proc(i) i };
     TaskPool::new(0, f);
 }