---

yaml
---
r: 115436
b: refs/heads/try
c: 8375a22
h: refs/heads/master
v: v3

Author: alexcrichton

[refs]

@@ -2,7 +2,7 @@
 refs/heads/master: bee4e6adac17f87b1cdc26ab69f8c0f5d82575a3
 refs/heads/snap-stage1: e33de59e47c5076a89eadeb38f4934f58a3618a6
 refs/heads/snap-stage3: ec0258a381b88b5574e3f8ce72ae553ac3a574b7
-refs/heads/try: b0977b1e0f7ba53b6301e2d5f7b26dd2d9c72fbf
+refs/heads/try: 8375a22b16ae6d746ccfd1f725a26562f55a82ba
 refs/tags/release-0.1: 1f5c5126e96c79d22cb7862f75304136e204f105
 refs/heads/ndm: f3868061cd7988080c30d6d5bf352a5a5fe2460b
 refs/heads/try2: 147ecfdd8221e4a4d4e090486829a06da1e0ca3c

branches/try/LICENSE-MIT

@@ -1,4 +1,5 @@
-Copyright (c) 2014 The Rust Project Developers
+Copyright (c) 2006-2009 Graydon Hoare
+Copyright (c) 2009-2014 Mozilla Foundation
 
 Permission is hereby granted, free of charge, to any
 person obtaining a copy of this software and associated

branches/try/RELEASES.txt

@@ -63,7 +63,7 @@ Version 0.10 (April 2014)
       documentation index page.
     * std: `std::condition` has been removed. All I/O errors are now propagated
       through the `Result` type. In order to assist with error handling, a
-      `try!` macro for unwrapping errors with an early return and a lint for
+      `try!` macro for unwrapping errors with an early return and an lint for
       unused results has been added. See #12039 for more information.
     * std: The `vec` module has been renamed to `slice`.
     * std: A new vector type, `Vec<T>`, has been added in preparation for DST.

branches/try/src/compiletest/header.rs

@@ -170,7 +170,7 @@ fn parse_compile_flags(line: &str) -> Option<~str> {
 }
 
 fn parse_run_flags(line: &str) -> Option<~str> {
-    parse_name_value_directive(line, "run-flags".to_owned())
+    parse_name_value_directive(line, ~"run-flags")
 }
 
 fn parse_debugger_cmd(line: &str) -> Option<~str> {

branches/try/src/doc/guide-container.md

@@ -120,13 +120,12 @@ differently.
 Containers implement iteration over the contained elements by returning an
 iterator object. For example, vector slices several iterators available:
 
-* `iter()` for immutable references to the elements
-* `mut_iter()` for mutable references to the elements
-* `move_iter()` to move the elements out by-value
+* `iter()` and `rev_iter()`, for immutable references to the elements
+* `mut_iter()` and `mut_rev_iter()`, for mutable references to the elements
+* `move_iter()` and `move_rev_iter()`, to move the elements out by-value
 
 A typical mutable container will implement at least `iter()`, `mut_iter()` and
-`move_iter()`. If it maintains an order, the returned iterators will be
-`DoubleEndedIterator`s, which are described below.
+`move_iter()` along with the reverse variants if it maintains an order.
 
 ### Freezing
 
@@ -266,7 +265,7 @@ Iterators offer generic conversion to containers with the `collect` adaptor:
 
 ~~~
 let xs = [0, 1, 1, 2, 3, 5, 8];
-let ys = xs.iter().rev().skip(1).map(|&x| x * 2).collect::<~[int]>();
+let ys = xs.rev_iter().skip(1).map(|&x| x * 2).collect::<~[int]>();
 assert_eq!(ys, ~[10, 6, 4, 2, 2, 0]);
 ~~~
 
@@ -359,6 +358,9 @@ for &x in it.rev() {
 }
 ~~~
 
+The `rev_iter` and `mut_rev_iter` methods on vectors just return an inverted
+version of the standard immutable and mutable vector iterators.
+
 The `chain`, `map`, `filter`, `filter_map` and `inspect` adaptors are
 `DoubleEndedIterator` implementations if the underlying iterators are.
 

branches/try/src/doc/guide-lifetimes.md

@@ -263,7 +263,7 @@ process is called *rooting*.
 The previous example demonstrated *rooting*, the process by which the
 compiler ensures that managed boxes remain live for the duration of a
 borrow. Unfortunately, rooting does not work for borrows of owned
-boxes, because it is not possible to have two references to an owned
+boxes, because it is not possible to have two references to a owned
 box.
 
 For owned boxes, therefore, the compiler will only allow a borrow *if
@@ -462,7 +462,7 @@ of a `f64` as if it were a struct with two fields would be a memory
 safety violation.
 
 So, in fact, for every `ref` binding, the compiler will impose the
-same rules as the ones we saw for borrowing the interior of an owned
+same rules as the ones we saw for borrowing the interior of a owned
 box: it must be able to guarantee that the `enum` will not be
 overwritten for the duration of the borrow.  In fact, the compiler
 would accept the example we gave earlier. The example is safe because

branches/try/src/doc/guide-pointers.md

@@ -186,7 +186,7 @@ enum List<T> {
     Nil,
     Cons(T, ~List<T>),
 }
-
+    
 fn main() {
     let list: List<int> = Cons(1, ~Cons(2, ~Cons(3, ~Nil)));
     println!("{:?}", list);
@@ -251,7 +251,7 @@ struct.
 
 > **Note**: the `@` form of managed pointers is deprecated and behind a
 > feature gate (it requires a `#![feature(managed_pointers)]` attribute on
-> the crate root). There are replacements, currently
+> the crate root; remember the semicolon!). There are replacements, currently 
 > there is `std::rc::Rc` and `std::gc::Gc` for shared ownership via reference
 > counting and garbage collection respectively.
 
@@ -266,7 +266,7 @@ struct Point {
     x: int,
     y: int,
 }
-
+    
 fn main() {
     let a = ~Point { x: 10, y: 20 };
     let b = a;
@@ -297,7 +297,7 @@ struct Point {
     x: int,
     y: int,
 }
-
+    
 fn main() {
     let a = @Point { x: 10, y: 20 };
     let b = a;
@@ -361,7 +361,7 @@ So how is this hard? Well, because we're ignoring ownership, the compiler needs
 to take great care to make sure that everything is safe. Despite their complete
 safety, a reference's representation at runtime is the same as that of
 an ordinary pointer in a C program. They introduce zero overhead. The compiler
-does all safety checks at compile time.
+does all safety checks at compile time. 
 
 This theory is called 'region pointers,' and involve a concept called
 'lifetimes'. Here's the simple explanation: would you expect this code to
@@ -477,7 +477,7 @@ fn main() {
 You may think that this gives us terrible performance: return a value and then
 immediately box it up?!?! Isn't that the worst of both worlds? Rust is smarter
 than that. There is no copy in this code. `main` allocates enough room for the
-`@int`, passes a pointer to that memory into `foo` as `x`, and then `foo` writes
+`@int`, passes a pointer to that memory into `foo` as `x`, and then `foo` writes 
 the value straight into that pointer. This writes the return value directly into
 the allocated box.
 

branches/try/src/doc/guide-tasks.md

@@ -101,8 +101,6 @@ fn print_message() { println!("I am running in a different task!"); }
 spawn(print_message);
 
 // Print something more profound in a different task using a lambda expression
-// This uses the proc() keyword to assign to spawn a function with no name
-// That function will call println!(...) as requested
 spawn(proc() println!("I am also running in a different task!") );
 ~~~~
 

branches/try/src/doc/guide-unsafe.md

@@ -56,7 +56,7 @@ standard library types, e.g. `Cell` and `RefCell`, that provide inner
 mutability by replacing compile time guarantees with dynamic checks at
 runtime.
 
-An `&mut` reference has a stronger requirement: when an object has an
+An `&mut` reference has a stronger requirement: when a object has an
 `&mut T` pointing into it, then that `&mut` reference must be the only
 such usable path to that object in the whole program. That is, an
 `&mut` cannot alias with any other references.

branches/try/src/doc/rust.md

@@ -161,7 +161,7 @@ Comments in Rust code follow the general C++ style of line and block-comment for
 with no nesting of block-comment delimiters.
 
 Line comments beginning with exactly _three_ slashes (`///`), and block
-comments beginning with exactly one repeated asterisk in the block-open
+comments beginning with a exactly one repeated asterisk in the block-open
 sequence (`/**`), are interpreted as a special syntax for `doc`
 [attributes](#attributes).  That is, they are equivalent to writing
 `#[doc="..."]` around the body of the comment (this includes the comment
@@ -365,7 +365,7 @@ of integer literal suffix:
     give the literal the corresponding machine type.
 
 The type of an _unsuffixed_ integer literal is determined by type inference.
-If an integer type can be _uniquely_ determined from the surrounding program
+If a integer type can be _uniquely_ determined from the surrounding program
 context, the unsuffixed integer literal has that type.  If the program context
 underconstrains the type, the unsuffixed integer literal's type is `int`; if
 the program context overconstrains the type, it is considered a static type
@@ -2184,7 +2184,7 @@ Supported traits for `deriving` are:
 * `Hash`, to iterate over the bytes in a data type.
 * `Rand`, to create a random instance of a data type.
 * `Default`, to create an empty instance of a data type.
-* `Zero`, to create a zero instance of a numeric data type.
+* `Zero`, to create an zero instance of a numeric data type.
 * `FromPrimitive`, to create an instance from a numeric primitive.
 * `Show`, to format a value using the `{}` formatter.
 

branches/try/src/doc/tutorial.md

@@ -1197,7 +1197,7 @@ fn eq(xs: &List, ys: &List) -> bool {
     match (xs, ys) {
         // If we have reached the end of both lists, they are equal.
         (&Nil, &Nil) => true,
-        // If the current elements of both lists are equal, keep going.
+        // If the current element in both lists is equal, keep going.
         (&Cons(x, ~ref next_xs), &Cons(y, ~ref next_ys))
                 if x == y => eq(next_xs, next_ys),
         // If the current elements are not equal, the lists are not equal.
@@ -1304,7 +1304,7 @@ fn eq<T: Eq>(xs: &List<T>, ys: &List<T>) -> bool {
     match (xs, ys) {
         // If we have reached the end of both lists, they are equal.
         (&Nil, &Nil) => true,
-        // If the current elements of both lists are equal, keep going.
+        // If the current element in both lists is equal, keep going.
         (&Cons(ref x, ~ref next_xs), &Cons(ref y, ~ref next_ys))
                 if x == y => eq(next_xs, next_ys),
         // If the current elements are not equal, the lists are not equal.
@@ -1333,7 +1333,7 @@ impl<T: Eq> Eq for List<T> {
         match (self, ys) {
             // If we have reached the end of both lists, they are equal.
             (&Nil, &Nil) => true,
-            // If the current elements of both lists are equal, keep going.
+            // If the current element in both lists is equal, keep going.
             (&Cons(ref x, ~ref next_xs), &Cons(ref y, ~ref next_ys))
                     if x == y => next_xs == next_ys,
             // If the current elements are not equal, the lists are not equal.
@@ -1720,103 +1720,38 @@ environment (sometimes referred to as "capturing" variables in their
 environment). For example, you couldn't write the following:
 
 ~~~~ {.ignore}
-let x = 3;
+let foo = 10;
 
-// `fun` cannot refer to `x`
-fn fun() -> () { println!("{}", x); }
+fn bar() -> int {
+   return foo; // `bar` cannot refer to `foo`
+}
 ~~~~
 
-A _closure_ does support accessing the enclosing scope; below we will create
-2 _closures_ (nameless functions). Compare how `||` replaces `()` and how
-they try to access `x`:
-
-~~~~ {.ignore}
-let x = 3;
-
-// `fun` is an invalid definition
-fn  fun       () -> () { println!("{}", x) }  // cannot capture from enclosing scope
-let closure = || -> () { println!("{}", x) }; // can capture from enclosing scope
+Rust also supports _closures_, functions that can access variables in
+the enclosing scope.
 
-// `fun_arg` is an invalid definition
-fn  fun_arg       (arg: int) -> () { println!("{}", arg + x) }  // cannot capture
-let closure_arg = |arg: int| -> () { println!("{}", arg + x) }; // can capture
-//                      ^
-// Requires a type because the implementation needs to know which `+` to use.
-// In the future, the implementation may not need the help.
+~~~~
+fn call_closure_with_ten(b: |int|) { b(10); }
 
-fun();          // Still won't work
-closure();      // Prints: 3
+let captured_var = 20;
+let closure = |arg| println!("captured_var={}, arg={}", captured_var, arg);
 
-fun_arg(7);     // Still won't work
-closure_arg(7); // Prints: 10
+call_closure_with_ten(closure);
 ~~~~
 
 Closures begin with the argument list between vertical bars and are followed by
 a single expression. Remember that a block, `{ <expr1>; <expr2>; ... }`, is
 considered a single expression: it evaluates to the result of the last
 expression it contains if that expression is not followed by a semicolon,
-otherwise the block evaluates to `()`, the unit value.
-
-In general, return types and all argument types must be specified
-explicitly for function definitions.  (As previously mentioned in the
-[Functions section](#functions), omitting the return type from a
-function declaration is synonymous with an explicit declaration of
-return type unit, `()`.)
-
-~~~~ {.ignore}
-fn  fun   (x: int)         { println!("{}", x) } // this is same as saying `-> ()`
-fn  square(x: int) -> uint { (x * x) as uint }   // other return types are explicit
-
-// Error: mismatched types: expected `()` but found `uint`
-fn  badfun(x: int)         { (x * x) as uint }
-~~~~
-
-On the other hand, the compiler can usually infer both the argument
-and return types for a closure expression; therefore they are often
-omitted, since both a human reader and the compiler can deduce the
-types from the immediate context.  This is in contrast to function
-declarations, which require types to be specified and are not subject
-to type inference. Compare:
+otherwise the block evaluates to `()`.
 
-~~~~ {.ignore}
-// `fun` as a function declaration cannot infer the type of `x`, so it must be provided
-fn  fun       (x: int) { println!("{}", x) }
-let closure = |x     | { println!("{}", x) }; // infers `x: int`, return type `()`
-
-// For closures, omitting a return type is *not* synonymous with `-> ()`
-let add_3   = |y     | { 3i + y }; // infers `y: int`, return type `int`.
-
-fun(10);            // Prints 10
-closure(20);        // Prints 20
-closure(add_3(30)); // Prints 33
+The types of the arguments are generally omitted, as is the return type,
+because the compiler can almost always infer them. In the rare case where the
+compiler needs assistance, though, the arguments and return types may be
+annotated.
 
-fun("String"); // Error: mismatched types
-
-// Error: mismatched types
-// inference already assigned `closure` the type `|int| -> ()`
-closure("String");
 ~~~~
-
-In cases where the compiler needs assistance, the arguments and return
-types may be annotated on closures, using the same notation as shown
-earlier.  In the example below, since different types provide an
-implementation for the operator `*`, the argument type for the `x`
-parameter must be explicitly provided.
-
-~~~~{.ignore}
-// Error: the type of `x` must be known to be used with `x * x`
-let square = |x     | -> uint { (x * x) as uint };
-~~~~
-
-In the corrected version, the argument type is explicitly annotated,
-while the return type can still be inferred.
-
-~~~~
-let square_explicit = |x: int| -> uint { (x * x) as uint };
-let square_infer    = |x: int|         { (x * x) as uint };
-
-println!("{}", square_explicit(20));  // 400
-println!("{}", square_infer(-20));    // 400
+let square = |x: int| -> uint { (x * x) as uint };
 ~~~~
 
 There are several forms of closure, each with its own role. The most
@@ -3030,7 +2965,7 @@ use farm::*;
 ~~~
 
 > *Note:* This feature of the compiler is currently gated behind the
-> `#![feature(globs)]` directive. More about these directives can be found in
+> `#[feature(globs)]` directive. More about these directives can be found in
 > the manual.
 
 However, that's not all. You can also rename an item while you're bringing it into scope:
@@ -3045,7 +2980,7 @@ fn main() {
 }
 ~~~
 
-In general, `use` creates a local alias:
+In general, `use` creates an local alias:
 An alternate path and a possibly different name to access the same item,
 without touching the original, and with both being interchangeable.
 

branches/try/src/etc/emacs/README.md

@@ -12,12 +12,11 @@ To install manually, check out this repository and add this to your
 
 ```lisp
 (add-to-list 'load-path "/path/to/rust-mode/")
-(autoload 'rust-mode "rust-mode" nil t)
-(add-to-list 'auto-mode-alist '("\\.rs\\'" . rust-mode))
+(require 'rust-mode)
 ```
 
-This associates `rust-mode` with `.rs` files. To enable it explicitly, do
-<kbd>M-x rust-mode</kbd>.
+`rust-mode` will automatically be associated with `.rs` files. To enable it
+explicitly, do <kbd>M-x rust-mode</kbd>.
 
 ### `package.el` installation via Marmalade or MELPA
 

branches/try/src/etc/emacs/rust-mode.el

@@ -169,7 +169,7 @@
 ;; Font-locking definitions and helpers
 (defconst rust-mode-keywords
   '("as"
-    "box" "break"
+    "break"
     "continue" "crate"
     "do"
     "else" "enum" "extern"

branches/try/src/etc/zsh/_rust

@@ -68,7 +68,7 @@ _rustc_opts_lint=(
     'unsafe-block[usage of an `unsafe` block]'
     'unstable[detects use of #\[unstable\] items (incl. items with no stability attribute)]'
     'unused-imports[imports that are never used]'
-    'unused-must-use[unused result of a type flagged as #\[must_use\]]'
+    'unused-must-use[unused result of an type flagged as #\[must_use\]]'
     "unused-mut[detect mut variables which don't need to be mutable]"
     'unused-result[unused result of an expression in a statement]'
     'unused-unsafe[unnecessary use of an `unsafe` block]'