---

yaml
---
r: 175935
b: refs/heads/try
c: b704983
h: refs/heads/master
i:
  175933: bd6f7c1
  175931: c33ece6
  175927: ad02072
  175919: 8bbe9a2
  175903: 81b844c
  175871: 959c417
v: v3

Author: steveklabnik

[refs]

@@ -2,7 +2,7 @@
 refs/heads/master: a530cc9706324ad44dba464d541a807eb5afdb08
 refs/heads/snap-stage1: e33de59e47c5076a89eadeb38f4934f58a3618a6
 refs/heads/snap-stage3: 777435990e0e91df6b72ce80c9b6fa485eeb5daa
-refs/heads/try: b8751b841096c904df62cbbf36885509e26a58a9
+refs/heads/try: b704983ee925dff219ecc5b8e7dd2ba9fec64c1f
 refs/tags/release-0.1: 1f5c5126e96c79d22cb7862f75304136e204f105
 refs/heads/dist-snap: ba4081a5a8573875fed17545846f6f6902c8ba8d
 refs/tags/release-0.2: c870d2dffb391e14efb05aa27898f1f6333a9596

branches/try/configure

@@ -448,10 +448,6 @@ case $CFG_CPUTYPE in
         CFG_CPUTYPE=aarch64
         ;;
 
-    powerpc)
-        CFG_CPUTYPE=powerpc
-        ;;
-
     x86_64 | x86-64 | x64 | amd64)
         CFG_CPUTYPE=x86_64
         ;;
@@ -1008,7 +1004,7 @@ do
     make_dir $t/rt/jemalloc
     for i in                                          \
       isaac sync test \
-      arch/i386 arch/x86_64 arch/arm arch/aarch64 arch/mips arch/powerpc
+      arch/i386 arch/x86_64 arch/arm arch/aarch64 arch/mips
     do
       make_dir $t/rt/stage$s/$i
     done
@@ -1173,7 +1169,7 @@ do
 
         msg "configuring LLVM for $gnu_t"
 
-        LLVM_TARGETS="--enable-targets=x86,x86_64,arm,aarch64,mips,powerpc"
+        LLVM_TARGETS="--enable-targets=x86,x86_64,arm,aarch64,mips"
         LLVM_BUILD="--build=$gnu_t"
         LLVM_HOST="--host=$gnu_t"
         LLVM_TARGET="--target=$gnu_t"

branches/try/mk/cfg/aarch64-apple-ios.mk

@@ -11,7 +11,7 @@ AR_aarch64-apple-ios = $(shell xcrun -find -sdk iphoneos ar)
 endif
 CFG_LIB_NAME_aarch64-apple-ios = lib$(1).a
 CFG_LIB_GLOB_aarch64-apple-ios = lib$(1)-*.a
-CFG_INSTALL_ONLY_RLIB_aarch64-apple-ios = 1
+CFG_LIB_SKIP_INSTALL_aarch64-apple-ios = 1 #lib$(1)-*.a
 CFG_STATIC_LIB_NAME_aarch64-apple-ios=lib$(1).a
 CFG_LIB_DSYM_GLOB_aarch64-apple-ios = lib$(1)-*.a.dSYM
 CFG_CFLAGS_aarch64-apple-ios := $(CFG_IOS_SDK_FLAGS_aarch64-apple-ios)

branches/try/mk/cfg/armv7-apple-ios.mk

@@ -11,7 +11,7 @@ AR_armv7-apple-ios = $(shell xcrun -find -sdk iphoneos ar)
 endif
 CFG_LIB_NAME_armv7-apple-ios = lib$(1).a
 CFG_LIB_GLOB_armv7-apple-ios = lib$(1)-*.a
-CFG_INSTALL_ONLY_RLIB_armv7-apple-ios = 1
+CFG_LIB_SKIP_INSTALL_armv7-apple-ios = 1 #lib$(1)-*.a
 CFG_STATIC_LIB_NAME_armv7-apple-ios=lib$(1).a
 CFG_LIB_DSYM_GLOB_armv7-apple-ios = lib$(1)-*.a.dSYM
 CFG_JEMALLOC_CFLAGS_armv7-apple-ios := -arch armv7 -mfpu=vfp3 $(CFG_IOS_SDK_FLAGS_armv7-apple-ios)

branches/try/mk/cfg/armv7s-apple-ios.mk

@@ -11,7 +11,7 @@ AR_armv7s-apple-ios = $(shell xcrun -find -sdk iphoneos ar)
 endif
 CFG_LIB_NAME_armv7s-apple-ios = lib$(1).a
 CFG_LIB_GLOB_armv7s-apple-ios = lib$(1)-*.a
-CFG_INSTALL_ONLY_RLIB_armv7s-apple-ios = 1
+CFG_LIB_SKIP_INSTALL_armv7s-apple-ios = 1 #lib$(1)-*.a
 CFG_STATIC_LIB_NAME_armv7s-apple-ios=lib$(1).a
 CFG_LIB_DSYM_GLOB_armv7s-apple-ios = lib$(1)-*.a.dSYM
 CFG_JEMALLOC_CFLAGS_armv7s-apple-ios := -arch armv7s -mfpu=vfp4 $(CFG_IOS_SDK_FLAGS_armv7s-apple-ios)

branches/try/mk/cfg/i386-apple-ios.mk

@@ -11,7 +11,6 @@ AR_i386-apple-ios = $(shell xcrun -find -sdk iphonesimulator ar)
 endif
 CFG_LIB_NAME_i386-apple-ios = lib$(1).a
 CFG_LIB_GLOB_i386-apple-ios = lib$(1)-*.dylib
-CFG_INSTALL_ONLY_RLIB_i386-apple-ios = 1
 CFG_STATIC_LIB_NAME_i386-apple-ios=lib$(1).a
 CFG_LIB_DSYM_GLOB_i386-apple-ios = lib$(1)-*.dylib.dSYM
 CFG_GCCISH_CFLAGS_i386-apple-ios := -Wall -Werror -g -fPIC -m32 $(CFG_IOSSIM_FLAGS_i386-apple-ios)

branches/try/mk/cfg/powerpc-unknown-linux-gnu.mk

@@ -11,7 +11,7 @@ AR_x86_64-apple-ios = $(shell xcrun -find -sdk iphonesimulator ar)
 endif
 CFG_LIB_NAME_x86_64-apple-ios = lib$(1).a
 CFG_LIB_GLOB_x86_64-apple-ios = lib$(1)-*.a
-CFG_INSTALL_ONLY_RLIB_x86_64-apple-ios = 1
+CFG_LIB_SKIP_INSTALL_x86_64-apple-ios = 1 #lib$(1)-*.a
 CFG_STATIC_LIB_NAME_x86_64-apple-ios=lib$(1).a
 CFG_LIB_DSYM_GLOB_x86_64-apple-ios = lib$(1)-*.a.dSYM
 CFG_CFLAGS_x86_64-apple-ios := $(CFG_IOSSIM_FLAGS_x86_64-apple-ios)

branches/try/mk/cfg/x86_64-apple-ios.mk

@@ -263,7 +263,7 @@ endif
 ######################################################################
 
 # FIXME: x86-ism
-LLVM_COMPONENTS=x86 arm aarch64 mips powerpc ipo bitreader bitwriter linker asmparser mcjit \
+LLVM_COMPONENTS=x86 arm aarch64 mips ipo bitreader bitwriter linker asmparser mcjit \
                 interpreter instrumentation
 
 # Only build these LLVM tools

branches/try/mk/main.mk

@@ -177,7 +177,7 @@ define CFG_MAKE_TOOLCHAIN
         $$(CFG_GCCISH_DEF_FLAG_$(1))$$(3) $$(2) \
         $$(call CFG_INSTALL_NAME_$(1),$$(4))
 
-  ifeq ($$(findstring $(HOST_$(1)),arm aarch64 mips mipsel powerpc),)
+  ifeq ($$(findstring $(HOST_$(1)),arm aarch64 mips mipsel),)
 
   # We're using llvm-mc as our assembler because it supports
   # .cfi pseudo-ops on mac
@@ -189,7 +189,7 @@ define CFG_MAKE_TOOLCHAIN
                     -o=$$(1)
   else
 
-  # For the ARM, AARCH64, MIPS and POWER crosses, use the toolchain assembler
+  # For the ARM, AARCH64 and MIPS crosses, use the toolchain assembler
   # FIXME: We should be able to use the LLVM assembler
   CFG_ASSEMBLE_$(1)=$$(CC_$(1)) $$(CFG_GCCISH_CFLAGS_$(1)) \
 		    $$(CFG_DEPEND_FLAGS) $$(2) -c -o $$(1)

branches/try/mk/platform.mk

@@ -134,7 +134,7 @@ prepare-target-$(2)-host-$(3)-$(1)-$(4): prepare-maybe-clean-$(4) \
         $$(if $$(findstring $(3), $$(PREPARE_HOST)), \
           $$(call PREPARE_DIR,$$(PREPARE_WORKING_DEST_LIB_DIR)) \
           $$(foreach crate,$$(TARGET_CRATES), \
-	    $$(if $$(or $$(findstring 1, $$(ONLY_RLIB_$$(crate))),$$(findstring 1,$$(CFG_INSTALL_ONLY_RLIB_$(2)))),, \
+	    $$(if $$(findstring 1, $$(ONLY_RLIB_$$(crate))),, \
               $$(call PREPARE_LIB,$$(call CFG_LIB_GLOB_$(2),$$(crate)))) \
             $$(call PREPARE_LIB,$$(call CFG_RLIB_GLOB,$$(crate)))) \
           $$(if $$(findstring $(2),$$(CFG_HOST)), \

branches/try/mk/prepare.mk

@@ -392,21 +392,20 @@ Here's an example of a concurrent Rust program:
 use std::thread::Thread;
 
 fn main() {
-    let guards: Vec<_> = (0..10).map(|_| {
-        Thread::scoped(|| {
+    for _ in range(0u, 10u) {
+        Thread::spawn(move || {
             println!("Hello, world!");
-        })
-    }).collect();
+        });
+    }
 }
 ```
 
-This program creates ten threads, which all print `Hello, world!`. The `scoped`
-function takes one argument, a closure, indicated by the double bars `||`. This
-closure is executed in a new thread created by `scoped`. The method is called
-`scoped` because it returns a 'join guard', which will automatically join the
-child thread when it goes out of scope. Because we `collect` these guards into
-a `Vec<T>`, and that vector goes out of scope at the end of our program, our
-program will wait for every thread to finish before finishing.
+This program creates ten threads, who all print `Hello, world!`. The
+`spawn` function takes one argument, a closure, indicated by the
+double bars `||`. (The `move` keyword indicates that the closure takes
+ownership of any data it uses; we'll have more on the significance of
+this shortly.) This closure is executed in a new thread created by
+`spawn`.
 
 One common form of problem in concurrent programs is a 'data race.'
 This occurs when two different threads attempt to access the same

branches/try/src/doc/intro.md

@@ -12,20 +12,17 @@ Looks like you've taken a wrong turn.
 Some things that might be helpful to you though:
 
 ## Search
-
 * <form action="https://duckduckgo.com/">
     <input type="text" id="site-search" name="q" size="80"></input>
     <input type="submit" value="Search DuckDuckGo">
 </form>
 * Rust doc search: <span id="core-search"></span>
 
 ## Reference
-
 * [The Rust official site](http://rust-lang.org)
-* [The Rust reference](http://doc.rust-lang.org/reference.html)
+* [The Rust reference](http://doc.rust-lang.org/reference.html) (* [PDF](http://doc.rust-lang.org/reference.pdf))
 
 ## Docs
-
 * [The standard library](http://doc.rust-lang.org/std/)
 
 <script>

branches/try/src/doc/not_found.md

@@ -2170,7 +2170,7 @@ arbitrarily complex configurations through nesting.
 The following configurations must be defined by the implementation:
 
 * `target_arch = "..."`. Target CPU architecture, such as `"x86"`, `"x86_64"`
-  `"mips"`, `"powerpc"`, `"arm"`, or `"aarch64"`.
+  `"mips"`, `"arm"`, or `"aarch64"`.
 * `target_endian = "..."`. Endianness of the target CPU, either `"little"` or
   `"big"`.
 * `target_family = "..."`. Operating system family of the target, e. g.
@@ -2432,15 +2432,15 @@ There are three different types of inline attributes:
 * `#[inline(always)]` asks the compiler to always perform an inline expansion.
 * `#[inline(never)]` asks the compiler to never perform an inline expansion.
 
-### Derive
+### Deriving
 
-The `derive` attribute allows certain traits to be automatically implemented
+The `deriving` attribute allows certain traits to be automatically implemented
 for data structures. For example, the following will create an `impl` for the
 `PartialEq` and `Clone` traits for `Foo`, the type parameter `T` will be given
 the `PartialEq` or `Clone` constraints for the appropriate `impl`:
 
 ```
-#[derive(PartialEq, Clone)]
+#[deriving(PartialEq, Clone)]
 struct Foo<T> {
     a: int,
     b: T
@@ -2462,7 +2462,7 @@ impl<T: PartialEq> PartialEq for Foo<T> {
 }
 ```
 
-Supported traits for `derive` are:
+Supported traits for `deriving` are:
 
 * Comparison traits: `PartialEq`, `Eq`, `PartialOrd`, `Ord`.
 * Serialization: `Encodable`, `Decodable`. These require `serialize`.
@@ -2967,8 +2967,8 @@ _panicked state_.
 
 ### Unary operator expressions
 
-Rust defines three unary operators. They are all written as prefix operators,
-before the expression they apply to.
+Rust defines six symbolic unary operators. They are all written as prefix
+operators, before the expression they apply to.
 
 * `-`
   : Negation. May only be applied to numeric types.
@@ -2986,6 +2986,13 @@ before the expression they apply to.
   : Logical negation. On the boolean type, this flips between `true` and
     `false`. On integer types, this inverts the individual bits in the
     two's complement representation of the value.
+* `box`
+  : [Boxing](#pointer-types) operators. Allocate a box to hold the value they
+    are applied to, and store the value in it. `box` creates a box.
+* `&`
+  : Borrow operator. Returns a reference, pointing to its operand. The operand
+    of a borrow is statically proven to outlive the resulting pointer. If the
+    borrow-checker cannot prove this, it is a compilation error.
 
 ### Binary operator expressions
 

branches/try/src/doc/reference.md

@@ -198,7 +198,7 @@ Rustdoc also supplies some extra sugar for helping with some tedious
 documentation examples. If a line is prefixed with `# `, then the line
 will not show up in the HTML documentation, but it will be used when
 testing the code block (NB. the space after the `#` is required, so
-that one can still write things like `#[derive(Eq)]`).
+that one can still write things like `#[deriving(Eq)]`).
 
 ~~~md
 ```

branches/try/src/doc/rustdoc.md

@@ -8,7 +8,7 @@ memory safe without using garbage collection.
 "The Rust Programming Language" is split into three sections, which you can
 navigate through the menu on the left.
 
-<h2 class="section-header"><a href="basic.html">Basics</a></h2>
+## Basics
 
 This section is a linear introduction to the basic syntax and semantics of
 Rust. It has individual sections on each part of Rust's syntax, and culminates
@@ -17,15 +17,15 @@ in a small project: a guessing game.
 After reading "Basics," you will have a good foundation to learn more about
 Rust, and can write very simple programs.
 
-<h2 class="section-header"><a href="intermediate.html">Intermediate</a></h2>
+## Intermediate
 
 This section contains individual chapters, which are self-contained. They focus
 on specific topics, and can be read in any order.
 
 After reading "Intermediate," you will have a solid understanding of Rust,
 and will be able to understand most Rust code and write more complex programs.
 
-<h2 class="section-header"><a href="advanced.html">Advanced</a></h2>
+## Advanced
 
 In a similar fashion to "Intermediate," this section is full of individual,
 deep-dive chapters, which stand alone and can be read in any order. These

branches/try/src/doc/trpl/README.md

@@ -26,7 +26,7 @@
     * [Iterators](iterators.md)
     * [Generics](generics.md)
     * [Traits](traits.md)
-    * [Threads](threads.md)
+    * [Tasks](tasks.md)
     * [Error Handling](error-handling.md)
 * [III: Advanced Topics](advanced.md)
     * [FFI](ffi.md)

branches/try/src/doc/trpl/SUMMARY.md

@@ -82,7 +82,7 @@ arrays:
 
 ```{rust}
 let a = [0, 1, 2, 3, 4];
-let middle = &a[1..4];     // A slice of a: just the elements 1, 2, and 3
+let middle = a.slice(1, 4);     // A slice of a: just the elements [1,2,3]
 
 for e in middle.iter() {
     println!("{}", e);          // Prints 1, 2, 3

branches/try/src/doc/trpl/arrays-vectors-and-slices.md

@@ -181,7 +181,7 @@ errors that can occur.
 # Non-recoverable errors with `panic!`
 
 In the case of an error that is unexpected and not recoverable, the `panic!`
-macro will induce a panic. This will crash the current thread, and give an error:
+macro will induce a panic. This will crash the current task, and give an error:
 
 ```{rust,ignore}
 panic!("boom");
@@ -190,7 +190,7 @@ panic!("boom");
 gives
 
 ```text
-thread '<main>' panicked at 'boom', hello.rs:2
+task '<main>' panicked at 'boom', hello.rs:2
 ```
 
 when you run it.

branches/try/src/doc/trpl/error-handling.md

@@ -166,12 +166,12 @@ GitHub](https://github.com/thestinger/rust-snappy).
 
 # Stack management
 
-Rust threads by default run on a *large stack*. This is actually implemented as a
+Rust tasks by default run on a *large stack*. This is actually implemented as a
 reserving a large segment of the address space and then lazily mapping in pages
 as they are needed. When calling an external C function, the code is invoked on
 the same stack as the rust stack. This means that there is no extra
 stack-switching mechanism in place because it is assumed that the large stack
-for the rust thread is plenty for the C function to have.
+for the rust task is plenty for the C function to have.
 
 A planned future improvement (not yet implemented at the time of this writing)
 is to have a guard page at the end of every rust stack. No rust function will
@@ -184,8 +184,8 @@ For normal external function usage, this all means that there shouldn't be any
 need for any extra effort on a user's perspective. The C stack naturally
 interleaves with the rust stack, and it's "large enough" for both to
 interoperate. If, however, it is determined that a larger stack is necessary,
-there are appropriate functions in the thread spawning API to control the size of
-the stack of the thread which is spawned.
+there are appropriate functions in the task spawning API to control the size of
+the stack of the task which is spawned.
 
 # Destructors
 
@@ -320,15 +320,16 @@ In the previously given examples the callbacks are invoked as a direct reaction
 to a function call to the external C library.
 The control over the current thread is switched from Rust to C to Rust for the
 execution of the callback, but in the end the callback is executed on the
-same thread that called the function which triggered the callback.
+same thread (and Rust task) that lead called the function which triggered
+the callback.
 
 Things get more complicated when the external library spawns its own threads
 and invokes callbacks from there.
 In these cases access to Rust data structures inside the callbacks is
 especially unsafe and proper synchronization mechanisms must be used.
 Besides classical synchronization mechanisms like mutexes, one possibility in
 Rust is to use channels (in `std::comm`) to forward data from the C thread
-that invoked the callback into a Rust thread.
+that invoked the callback into a Rust task.
 
 If an asynchronous callback targets a special object in the Rust address space
 it is also absolutely necessary that no more callbacks are performed by the