---

yaml
---
r: 148726
b: refs/heads/try2
c: 5a61812
h: refs/heads/master
v: v3

Author: bors

[refs]

@@ -5,7 +5,7 @@ refs/heads/snap-stage3: 78a7676898d9f80ab540c6df5d4c9ce35bb50463
 refs/heads/try: 519addf6277dbafccbb4159db4b710c37eaa2ec5
 refs/tags/release-0.1: 1f5c5126e96c79d22cb7862f75304136e204f105
 refs/heads/ndm: f3868061cd7988080c30d6d5bf352a5a5fe2460b
-refs/heads/try2: 9b1865a7faafe16af9eb9f804e82065b5a6f1e24
+refs/heads/try2: 5a618129b842f875dac5531ce7b8385fe4fcda6c
 refs/heads/dist-snap: ba4081a5a8573875fed17545846f6f6902c8ba8d
 refs/tags/release-0.2: c870d2dffb391e14efb05aa27898f1f6333a9596
 refs/tags/release-0.3: b5f0d0f648d9a6153664837026ba1be43d3e2503

branches/try2/.gitignore

@@ -74,8 +74,10 @@ src/.DS_Store
 /doc/html
 /doc/latex
 /doc/std
+/doc/arena
 /doc/extra
 /doc/flate
+/doc/glob
 /doc/green
 /doc/native
 /doc/rustc

branches/try2/Makefile.in

@@ -124,7 +124,7 @@ endif
 ifdef TRACE
   CFG_RUSTC_FLAGS += -Z trace
 endif
-ifdef DISABLE_RPATH
+ifdef CFG_DISABLE_RPATH
 # NOTE: make this CFG_RUSTC_FLAGS after stage0 snapshot
 RUSTFLAGS_STAGE1 += --no-rpath
 RUSTFLAGS_STAGE2 += --no-rpath

branches/try2/configure

@@ -916,6 +916,10 @@ do
         LLVM_OPTS="$LLVM_OPTS --disable-terminfo"
         # Try to have LLVM pull in as few dependencies as possible (#9397)
         LLVM_OPTS="$LLVM_OPTS --disable-zlib --disable-libffi"
+        # LLVM says it needs a "new" clang/gcc, but we seem to get by ok with
+        # older versions on the bots. Get by for a little longer by asking it to
+        # not do version detection
+        LLVM_OPTS="$LLVM_OPTS --disable-compiler-version-checks"
 
         # Use win32 native thread/lock apis instead of pthread wrapper.
         # (llvm's configure tries to find pthread first, so we have to disable it explicitly.)

branches/try2/doc/guide-conditions.md

@@ -261,15 +261,15 @@ use std::task;
 fn main() {
 
     // Isolate failure within a subtask.
-    let result = do task::try {
+    let result = task::try(proc() {
 
         // The protected logic.
         let pairs = read_int_pairs();
         for &(a,b) in pairs.iter() {
             println!("{:4.4d}, {:4.4d}", a, b);
         }
 
-    };
+    });
     if result.is_err() {
             println!("parsing failed");
     }

branches/try2/doc/guide-pointers.md

@@ -221,9 +221,9 @@ struct Point {
 
 fn main() {
     let a = Point { x: 10, y: 20 };
-    do spawn {
+    spawn(proc() {
         println!("{}", a.x);
-    }
+    });
 }
 ~~~
 
@@ -238,9 +238,9 @@ struct Point {
 
 fn main() {
     let a = ~Point { x: 10, y: 20 };
-    do spawn {
+    spawn(proc() {
         println!("{}", a.x);
-    }
+    });
 }
 ~~~
 

branches/try2/doc/guide-runtime.md

@@ -236,9 +236,9 @@ extern mod green;
 
 #[start]
 fn start(argc: int, argv: **u8) -> int {
-    do green::start(argc, argv) {
+    green::start(argc, argv, proc() {
         main();
-    }
+    })
 }
 
 fn main() {}

branches/try2/doc/guide-tasks.md

@@ -77,11 +77,6 @@ spawn(print_message);
 
 // Print something more profound in a different task using a lambda expression
 spawn(proc() println!("I am also running in a different task!") );
-
-// The canonical way to spawn is using `do` notation
-do spawn {
-    println!("I too am running in a different task!");
-}
 ~~~~
 
 In Rust, there is nothing special about creating tasks: a task is not a
@@ -103,10 +98,10 @@ an environment that it carries across tasks.
 // Generate some state locally
 let child_task_number = generate_task_number();
 
-do spawn {
+spawn(proc() {
     // Capture it in the remote task
     println!("I am child number {}", child_task_number);
-}
+});
 ~~~
 
 ## Communication
@@ -132,10 +127,10 @@ concurrently:
 
 let (port, chan): (Port<int>, Chan<int>) = Chan::new();
 
-do spawn || {
+spawn(proc() {
     let result = some_expensive_computation();
     chan.send(result);
-}
+});
 
 some_other_expensive_computation();
 let result = port.recv();
@@ -160,10 +155,10 @@ spawns the child task.
 # use std::task::spawn;
 # fn some_expensive_computation() -> int { 42 }
 # let (port, chan) = Chan::new();
-do spawn || {
+spawn(proc() {
     let result = some_expensive_computation();
     chan.send(result);
-}
+});
 ~~~~
 
 Notice that the creation of the task closure transfers `chan` to the child
@@ -195,15 +190,15 @@ of tasks? The following program is ill-typed:
 # fn some_expensive_computation() -> int { 42 }
 let (port, chan) = Chan::new();
 
-do spawn {
+spawn(proc() {
     chan.send(some_expensive_computation());
-}
+});
 
 // ERROR! The previous spawn statement already owns the channel,
 // so the compiler will not allow it to be captured again
-do spawn {
+spawn(proc() {
     chan.send(some_expensive_computation());
-}
+});
 ~~~
 
 Instead we can use a `SharedChan`, a type that allows a single
@@ -217,9 +212,9 @@ let (port, chan) = SharedChan::new();
 for init_val in range(0u, 3) {
     // Create a new channel handle to distribute to the child task
     let child_chan = chan.clone();
-    do spawn {
+    spawn(proc() {
         child_chan.send(some_expensive_computation(init_val));
-    }
+    });
 }
 
 let result = port.recv() + port.recv() + port.recv();
@@ -247,9 +242,9 @@ might look like the example below.
 // Create a vector of ports, one for each child task
 let ports = vec::from_fn(3, |init_val| {
     let (port, chan) = Chan::new();
-    do spawn {
+    spawn(proc() {
         chan.send(some_expensive_computation(init_val));
-    }
+    });
     port
 });
 
@@ -296,7 +291,7 @@ fn partial_sum(start: uint) -> f64 {
 }
 
 fn main() {
-    let mut futures = vec::from_fn(1000, |ind| do extra::future::Future::spawn { partial_sum(ind) });
+    let mut futures = vec::from_fn(1000, |ind| extra::future::Future::spawn( proc() { partial_sum(ind) }));
 
     let mut final_res = 0f64;
     for ft in futures.mut_iter()  {
@@ -339,11 +334,11 @@ fn main() {
         let (port, chan)  = Chan::new();
         chan.send(numbers_arc.clone());
 
-        do spawn {
+        spawn(proc() {
             let local_arc : Arc<~[f64]> = port.recv();
             let task_numbers = local_arc.get();
             println!("{}-norm = {}", num, pnorm(task_numbers, num));
-        }
+        });
     }
 }
 ~~~
@@ -417,13 +412,13 @@ termination with an error).
 # use std::task;
 # fn some_condition() -> bool { false }
 # fn calculate_result() -> int { 0 }
-let result: Result<int, ()> = do task::try {
+let result: Result<int, ()> = task::try(proc() {
     if some_condition() {
         calculate_result()
     } else {
         fail!("oops!");
     }
-};
+});
 assert!(result.is_err());
 ~~~
 
@@ -502,9 +497,9 @@ Here is the code for the parent task:
 
 let (from_child, to_child) = DuplexStream::new();
 
-do spawn {
+spawn(proc() {
     stringifier(&to_child);
-};
+});
 
 from_child.send(22);
 assert!(from_child.recv() == ~"22");

branches/try2/doc/index.md

@@ -37,7 +37,9 @@ li {list-style-type: none; }
 * [The Rust parser, `libsyntax`](syntax/index.html)
 * [The Rust compiler, `librustc`](rustc/index.html)
 
+* [The `arena` allocation library](arena/index.html)
 * [The `flate` compression library](flate/index.html)
+* [The `glob` file path matching library](glob/index.html)
 
 # Tooling
 

branches/try2/doc/rust.md

@@ -2751,52 +2751,6 @@ but must enclose it.
 
 A `loop` expression is only permitted in the body of a loop.
 
-### Do expressions
-
-~~~~ {.ebnf .gram}
-do_expr : "do" expr [ '|' ident_list '|' ] ? '{' block '}' ;
-~~~~
-
-A _do expression_ provides a more-familiar block syntax
-for invoking a function and passing it a newly-created a procedure.
-
-The optional `ident_list` and `block` provided in a `do` expression are parsed
-as though they constitute a procedure expression;
-if the `ident_list` is missing, an empty `ident_list` is implied.
-
-The procedure expression is then provided as a _trailing argument_
-to the outermost [call](#call-expressions) or
-[method call](#method-call-expressions) expression
-in the `expr` following `do`.
-If the `expr` is a [path expression](#path-expressions), it is parsed as though it is a call expression.
-If the `expr` is a [field expression](#field-expressions), it is parsed as though it is a method call expression.
-
-In this example, both calls to `f` are equivalent:
-
-~~~~
-# fn f(f: proc(int)) { }
-# fn g(i: int) { }
-
-f(proc(j) { g(j) });
-
-do f |j| {
-    g(j);
-}
-~~~~
-
-In this example, both calls to the (binary) function `k` are equivalent:
-
-~~~~
-# fn k(x:int, f: proc(int)) { }
-# fn l(i: int) { }
-
-k(3, proc(j) { l(j) });
-
-do k(3) |j| {
-   l(j);
-}
-~~~~
-
 ### For expressions
 
 ~~~~ {.ebnf .gram}
@@ -2864,14 +2818,15 @@ match_pat : pat [ ".." pat ] ? [ "if" expr ] ;
 
 A `match` expression branches on a *pattern*. The exact form of matching that
 occurs depends on the pattern. Patterns consist of some combination of
-literals, destructured enum constructors, structures, records and tuples, variable binding
-specifications, wildcards (`..`), and placeholders (`_`). A `match` expression has a *head
-expression*, which is the value to compare to the patterns. The type of the
-patterns must equal the type of the head expression.
+literals, destructured vectors or enum constructors, structures, records and
+tuples, variable binding specifications, wildcards (`..`), and placeholders
+(`_`). A `match` expression has a *head expression*, which is the value to
+compare to the patterns. The type of the patterns must equal the type of the
+head expression.
 
-In a pattern whose head expression has an `enum` type, a placeholder (`_`) stands for a
-*single* data field, whereas a wildcard `..` stands for *all* the fields of a particular
-variant. For example:
+In a pattern whose head expression has an `enum` type, a placeholder (`_`)
+stands for a *single* data field, whereas a wildcard `..` stands for *all* the
+fields of a particular variant. For example:
 
 ~~~~
 enum List<X> { Nil, Cons(X, ~List<X>) }
@@ -2885,11 +2840,35 @@ match x {
 }
 ~~~~
 
-The first pattern matches lists constructed by applying `Cons` to any head value, and a
-tail value of `~Nil`. The second pattern matches _any_ list constructed with `Cons`,
-ignoring the values of its arguments. The difference between `_` and `..` is that the pattern
-`C(_)` is only type-correct if `C` has exactly one argument, while the pattern `C(..)` is
-type-correct for any enum variant `C`, regardless of how many arguments `C` has.
+The first pattern matches lists constructed by applying `Cons` to any head
+value, and a tail value of `~Nil`. The second pattern matches _any_ list
+constructed with `Cons`, ignoring the values of its arguments. The difference
+between `_` and `..` is that the pattern `C(_)` is only type-correct if `C` has
+exactly one argument, while the pattern `C(..)` is type-correct for any enum
+variant `C`, regardless of how many arguments `C` has.
+
+Used inside a vector pattern, `..` stands for any number of elements. This
+wildcard can be used at most once for a given vector, which implies that it
+cannot be used to specifically match elements that are at an unknown distance
+from both ends of a vector, like `[.., 42, ..]`. If followed by a variable name,
+it will bind the corresponding slice to the variable. Example:
+
+~~~~
+fn is_symmetric(list: &[uint]) -> bool {
+    match list {
+        [] | [_]                   => true,
+        [x, ..inside, y] if x == y => is_symmetric(inside),
+        _                          => false
+    }
+}
+
+fn main() {
+    let sym     = &[0, 1, 4, 2, 4, 1, 0];
+    let not_sym = &[0, 1, 7, 2, 4, 1, 0];
+    assert!(is_symmetric(sym));
+    assert!(!is_symmetric(not_sym));
+}
+~~~~
 
 A `match` behaves differently depending on whether or not the head expression
 is an [lvalue or an rvalue](#lvalues-rvalues-and-temporaries).
@@ -2972,7 +2951,7 @@ let z = match x { &0 => "zero", _ => "some" };
 assert_eq!(y, z);
 ~~~~
 
-A pattern that's just an identifier, like `Nil` in the previous answer,
+A pattern that's just an identifier, like `Nil` in the previous example,
 could either refer to an enum variant that's in scope, or bind a new variable.
 The compiler resolves this ambiguity by forbidding variable bindings that occur
 in `match` patterns from shadowing names of variants that are in scope.