Merge

Author: catamorphism

AUTHORS.txt

@@ -106,6 +106,7 @@ Margaret Meyerhofer <[email protected]>
 Marijn Haverbeke <[email protected]>
 Mark Lacey <[email protected]>
 Martin DeMello <[email protected]>
+Marvin Löbel <[email protected]>
 Matt Brubeck <[email protected]>
 Matthew O'Connor <[email protected]>
 Max Penet <[email protected]>

CONTRIBUTING.md

@@ -1,15 +1,24 @@
 ## Pull request procedure
 
-Pull requests should be targeted at Rust's `incoming` branch (note that by default Github will aim them at the `master` branch) -- see "Changing The Commit Range and Destination Repository" in Github's documentation on [pull requests](https://help.github.com/articles/using-pull-requests). Before pushing to your Github repo and issuing the pull request, please do two things:
+Pull requests should be targeted at Rust's `incoming` branch (note that by default Github will aim them at the `master` branch) --
+see "Changing The Commit Range and Destination Repository" in Github's documentation on [pull requests](https://help.github.com/articles/using-pull-requests).
+Before pushing to your Github repo and issuing the pull request, please do two things:
 
 1. [Rebase](http://git-scm.com/book/en/Git-Branching-Rebasing) your local changes against the `incoming` branch. Resolve any conflicts that arise.
-2. Run the full Rust test suite with the `make check` command. You're not off the hook even if you just stick to documentation; code examples in the docs are tested as well!
+2. Run the full Rust test suite with the `make check` command.
+You're not off the hook even if you just stick to documentation; code examples in the docs are tested as well!
 
-Pull requests will be treated as "review requests", and we will give feedback we expect to see corrected on [style](https://github.com/mozilla/rust/wiki/Note-style-guide) and substance before pulling. Changes contributed via pull request should focus on a single issue at a time, like any other. We will not look kindly on pull-requests that try to "sneak" unrelated changes in.
+Pull requests will be treated as "review requests",
+and we will give feedback we expect to see corrected on [style](https://github.com/mozilla/rust/wiki/Note-style-guide) and substance before pulling.
+Changes contributed via pull request should focus on a single issue at a time, like any other.
+We will not look accept pull-requests that try to "sneak" unrelated changes in.
 
-Normally, all pull requests must include regression tests (see [Note-testsuite](https://github.com/mozilla/rust/wiki/Note-testsuite)) that test your change. Occasionally, a change will be very difficult to test for. In those cases, please include a note in your commit message explaining why.
+Normally, all pull requests must include regression tests (see [Note-testsuite](https://github.com/mozilla/rust/wiki/Note-testsuite)) that test your change.
+Occasionally, a change will be very difficult to test for.
+In those cases, please include a note in your commit message explaining why.
 
-In the licensing header at the beginning of any files you change, please make sure the listed date range includes the current year. For example, if it's 2013, and you change a Rust file that was created in 2010, it should begin:
+In the licensing header at the beginning of any files you change, please make sure the listed date range includes the current year.
+For example, if it's 2013, and you change a Rust file that was created in 2010, it should begin:
 
 ```
 // Copyright 2010-2013 The Rust Project Developers.

README.md

@@ -42,7 +42,7 @@ packages:
 Assuming you're on a relatively modern *nix system and have met the
 prerequisites, something along these lines should work.
 
-    $ wget http://static.rust-lang.org/dist/rust-0.5.tar.gz
+    $ curl -O http://static.rust-lang.org/dist/rust-0.5.tar.gz
     $ tar -xzf rust-0.5.tar.gz
     $ cd rust-0.5
     $ ./configure

doc/lib/codemirror-rust.js

@@ -2,7 +2,7 @@ CodeMirror.defineMode("rust", function() {
   var indentUnit = 4, altIndentUnit = 2;
   var valKeywords = {
     "if": "if-style", "while": "if-style", "loop": "if-style", "else": "else-style",
-    "do": "else-style", "return": "else-style", "fail": "else-style",
+    "do": "else-style", "return": "else-style",
     "break": "atom", "cont": "atom", "const": "let", "resource": "fn",
     "let": "let", "fn": "fn", "for": "for", "match": "match", "trait": "trait",
     "impl": "impl", "type": "type", "enum": "enum", "struct": "atom", "mod": "mod",

doc/rust.md

@@ -216,7 +216,7 @@ break
 const copy
 do drop
 else enum extern
-fail false fn for
+false fn for
 if impl
 let log loop
 match mod move mut
@@ -448,10 +448,10 @@ expression context, the final namespace qualifier is omitted.
 Two examples of paths with type arguments:
 
 ~~~~
-# use std::map;
+# use std::oldmap;
 # fn f() {
 # fn id<T:Copy>(t: T) -> T { t }
-type t = map::HashMap<int,~str>;  // Type arguments used in a type expression
+type t = oldmap::HashMap<int,~str>;  // Type arguments used in a type expression
 let x = id::<int>(10);           // Type arguments used in a call expression
 # }
 ~~~~
@@ -692,15 +692,15 @@ mod math {
     type complex = (f64, f64);
     fn sin(f: f64) -> f64 {
         ...
-# fail;
+# die!();
     }
     fn cos(f: f64) -> f64 {
         ...
-# fail;
+# die!();
     }
     fn tan(f: f64) -> f64 {
         ...
-# fail;
+# die!();
     }
 }
 ~~~~~~~~
@@ -844,13 +844,16 @@ mod quux {
         pub fn bar() { }
         pub fn baz() { }
     }
-    
+
     pub use quux::foo::*;
 }
 ~~~~
 
 In this example, the module `quux` re-exports all of the public names defined in `foo`.
 
+Also note that the paths contained in `use` items are relative to the crate root; so, in the previous
+example, the use refers to `quux::foo::*`, and not simply to `foo::*`.
+
 ### Functions
 
 A _function item_ defines a sequence of [statements](#statements) and an optional final [expression](#expressions), along with a name and a set of parameters.
@@ -989,13 +992,13 @@ output slot type would normally be. For example:
 ~~~~
 fn my_err(s: &str) -> ! {
     log(info, s);
-    fail;
+    die!();
 }
 ~~~~
 
 We call such functions "diverging" because they never return a value to the
 caller. Every control path in a diverging function must end with a
-[`fail`](#fail-expressions) or a call to another diverging function on every
+`fail!()` or a call to another diverging function on every
 control path. The `!` annotation does *not* denote a type. Rather, the result
 type of a diverging function is a special type called $\bot$ ("bottom") that
 unifies with any type. Rust has no syntax for $\bot$.
@@ -1007,7 +1010,7 @@ were declared without the `!` annotation, the following code would not
 typecheck:
 
 ~~~~
-# fn my_err(s: &str) -> ! { fail }
+# fn my_err(s: &str) -> ! { die!() }
 
 fn f(i: int) -> int {
    if i == 42 {
@@ -1239,7 +1242,7 @@ trait Num {
 impl float: Num {
     static pure fn from_int(n: int) -> float { n as float }
 }
-let x: float = Num::from_int(42);     
+let x: float = Num::from_int(42);
 ~~~~
 
 Traits may inherit from other traits. For example, in
@@ -1612,7 +1615,7 @@ The following are examples of structure expressions:
 ~~~~
 # struct Point { x: float, y: float }
 # struct TuplePoint(float, float);
-# mod game { pub struct User { name: &str, age: uint, mut score: uint } } 
+# mod game { pub struct User { name: &str, age: uint, mut score: uint } }
 # use game;
 Point {x: 10f, y: 20f};
 TuplePoint(10f, 20f);
@@ -1716,15 +1719,12 @@ vec_elems : [expr [',' expr]*] | [expr ',' ".." expr]
 
 A [_vector_](#vector-types) _expression_ is written by enclosing zero or
 more comma-separated expressions of uniform type in square brackets.
-The keyword `mut` can be written after the opening bracket to
-indicate that the elements of the resulting vector may be mutated.
-When no mutability is specified, the vector is immutable.
 
 ~~~~
 [1, 2, 3, 4];
 ["a", "b", "c", "d"];
 [0, ..128];             // vector with 128 zeros
-[mut 0u8, 0u8, 0u8, 0u8];
+[0u8, 0u8, 0u8, 0u8];
 ~~~~
 
 ### Index expressions
@@ -1746,7 +1746,6 @@ task in a _failing state_.
 # do task::spawn_unlinked {
 
 ([1, 2, 3, 4])[0];
-([mut 'x', 'y'])[1] = 'z';
 (["a", "b"])[10]; // fails
 
 # }
@@ -1909,8 +1908,8 @@ No allocation or destruction is entailed.
 An example of three different swap expressions:
 
 ~~~~~~~~
-# let mut x = &[mut 0];
-# let mut a = &[mut 0];
+# let mut x = &mut [0];
+# let mut a = &mut [0];
 # let i = 0;
 # let y = {mut z: 0};
 # let b = {mut c: 0};
@@ -2005,11 +2004,11 @@ the unary copy operator is typically only used to cause an argument to a functio
 An example of a copy expression:
 
 ~~~~
-fn mutate(vec: ~[mut int]) {
+fn mutate(mut vec: ~[int]) {
    vec[0] = 10;
 }
 
-let v = ~[mut 1,2,3];
+let v = ~[1,2,3];
 
 mutate(copy v);   // Pass a copy
 
@@ -2291,9 +2290,9 @@ enum List<X> { Nil, Cons(X, @List<X>) }
 let x: List<int> = Cons(10, @Cons(11, @Nil));
 
 match x {
-    Cons(_, @Nil) => fail ~"singleton list",
+    Cons(_, @Nil) => die!(~"singleton list"),
     Cons(*)       => return,
-    Nil           => fail ~"empty list"
+    Nil           => die!(~"empty list")
 }
 ~~~~
 
@@ -2330,7 +2329,7 @@ match x {
         return;
     }
     _ => {
-        fail;
+        die!();
     }
 }
 ~~~~
@@ -2418,23 +2417,10 @@ guard may refer to the variables bound within the pattern they follow.
 let message = match maybe_digit {
   Some(x) if x < 10 => process_digit(x),
   Some(x) => process_other(x),
-  None => fail
+  None => die!()
 };
 ~~~~
 
-
-### Fail expressions
-
-~~~~~~~~{.ebnf .gram}
-fail_expr : "fail" expr ? ;
-~~~~~~~~
-
-Evaluating a `fail` expression causes a task to enter the *failing* state. In
-the *failing* state, a task unwinds its stack, destroying all frames and
-running all destructors until it reaches its entry frame, at which point it
-halts execution in the *dead* state.
-
-
 ### Return expressions
 
 ~~~~~~~~{.ebnf .gram}
@@ -2822,7 +2808,7 @@ trait Printable {
 }
 
 impl int: Printable {
-  fn to_str() -> ~str { int::to_str(self, 10) }
+  fn to_str() -> ~str { int::to_str(self) }
 }
 
 fn print(a: @Printable) {
@@ -3154,7 +3140,7 @@ unblock and transition back to *running*.
 
 A task may transition to the *failing* state at any time, due being
 killed by some external event or internally, from the evaluation of a
-`fail` expression. Once *failing*, a task unwinds its stack and
+`fail!()` macro. 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

doc/tutorial-macros.md

@@ -218,7 +218,7 @@ match x {
                 // complicated stuff goes here
                 return result + val;
             },
-            _ => fail ~"Didn't get good_2"
+            _ => die!(~"Didn't get good_2")
         }
     }
     _ => return 0 // default value
@@ -260,7 +260,7 @@ macro_rules! biased_match (
 biased_match!((x)       ~ (good_1(g1, val)) else { return 0 };
               binds g1, val )
 biased_match!((g1.body) ~ (good_2(result) )
-                  else { fail ~"Didn't get good_2" };
+                  else { die!(~"Didn't get good_2") };
               binds result )
 // complicated stuff goes here
 return result + val;
@@ -362,7 +362,7 @@ macro_rules! biased_match (
 # fn f(x: t1) -> uint {
 biased_match!(
     (x)       ~ (good_1(g1, val)) else { return 0 };
-    (g1.body) ~ (good_2(result) ) else { fail ~"Didn't get good_2" };
+    (g1.body) ~ (good_2(result) ) else { die!(~"Didn't get good_2") };
     binds val, result )
 // complicated stuff goes here
 return result + val;

doc/tutorial-tasks.md

@@ -13,7 +13,7 @@ cheaper to create than traditional threads, Rust can create hundreds of
 thousands of concurrent tasks on a typical 32-bit system.
 
 Tasks provide failure isolation and recovery. When an exception occurs in Rust
-code (as a result of an explicit call to `fail`, an assertion failure, or
+code (as a result of an explicit call to `fail!()`, an assertion failure, or
 another invalid operation), the runtime system destroys the entire
 task. Unlike in languages such as Java and C++, there is no way to `catch` an
 exception. Instead, tasks may monitor each other for failure.
@@ -296,9 +296,9 @@ let result = ports.foldl(0, |accum, port| *accum + port.recv() );
 
 # Handling task failure
 
-Rust has a built-in mechanism for raising exceptions. The `fail` construct
-(which can also be written with an error string as an argument: `fail
-~reason`) and the `assert` construct (which effectively calls `fail` if a
+Rust has a built-in mechanism for raising exceptions. The `fail!()` macro
+(which can also be written with an error string as an argument: `fail!(
+~reason)`) and the `assert` construct (which effectively calls `fail!()` if a
 boolean expression is false) are both ways to raise exceptions. When a task
 raises an exception the task unwinds its stack---running destructors and
 freeing memory along the way---and then exits. Unlike exceptions in C++,
@@ -313,7 +313,7 @@ of all tasks are intertwined: if one fails, so do all the others.
 # fn do_some_work() { loop { task::yield() } }
 # do task::try {
 // Create a child task that fails
-do spawn { fail }
+do spawn { die!() }
 
 // This will also fail because the task we spawned failed
 do_some_work();
@@ -337,7 +337,7 @@ let result: Result<int, ()> = do task::try {
     if some_condition() {
         calculate_result()
     } else {
-        fail ~"oops!";
+        die!(~"oops!");
     }
 };
 assert result.is_err();
@@ -354,7 +354,7 @@ an `Error` result.
 > ***Note:*** A failed task does not currently produce a useful error
 > value (`try` always returns `Err(())`). In the
 > future, it may be possible for tasks to intercept the value passed to
-> `fail`.
+> `fail!()`.
 
 TODO: Need discussion of `future_result` in order to make failure
 modes useful.
@@ -377,7 +377,7 @@ either task dies, it kills the other one.
 # do task::try {
 do task::spawn {
     do task::spawn {
-        fail;  // All three tasks will die.
+        die!();  // All three tasks will die.
     }
     sleep_forever();  // Will get woken up by force, then fail
 }
@@ -432,7 +432,7 @@ do task::spawn_supervised {
     // Intermediate task immediately exits
 }
 wait_for_a_while();
-fail;  // Will kill grandchild even if child has already exited
+die!();  // Will kill grandchild even if child has already exited
 # };
 ~~~
 
@@ -446,10 +446,10 @@ other at all, using `task::spawn_unlinked` for _isolated failure_.
 let (time1, time2) = (random(), random());
 do task::spawn_unlinked {
     sleep_for(time2);  // Won't get forced awake
-    fail;
+    die!();
 }
 sleep_for(time1);  // Won't get forced awake
-fail;
+die!();
 // It will take MAX(time1,time2) for the program to finish.
 # };
 ~~~
@@ -473,7 +473,7 @@ fn stringifier(channel: &DuplexStream<~str, uint>) {
     let mut value: uint;
     loop {
         value = channel.recv();
-        channel.send(uint::to_str(value, 10));
+        channel.send(uint::to_str(value));
         if value == 0 { break; }
     }
 }
@@ -497,7 +497,7 @@ Here is the code for the parent task:
 #     let mut value: uint;
 #     loop {
 #         value = channel.recv();
-#         channel.send(uint::to_str(value, 10u));
+#         channel.send(uint::to_str(value));
 #         if value == 0u { break; }
 #     }
 # }