---

yaml
---
r: 216831
b: refs/heads/stable
c: 4d1e48e
h: refs/heads/master
i:
  216829: b44a887
  216827: 2526ccd
  216823: 4b70128
  216815: 6600962
  216799: c54a02a
  216767: de71cdf
  216703: 71b7b5b
  216575: 0d20320
v: v3

Author: tincann

[refs]

@@ -29,5 +29,5 @@ refs/heads/tmp: 378a370ff2057afeb1eae86eb6e78c476866a4a6
 refs/tags/1.0.0-alpha.2: 4c705f6bc559886632d3871b04f58aab093bfa2f
 refs/tags/homu-tmp: a5286998df566e736b32f6795bfc3803bdaf453d
 refs/tags/1.0.0-beta: 8cbb92b53468ee2b0c2d3eeb8567005953d40828
-refs/heads/stable: ad1c0c57b8710a569a2ed573a1d47b98fe5616b1
+refs/heads/stable: 4d1e48e37610f421f30e098f2ae9ef98b85b66eb
 refs/tags/1.0.0: 55bd4f8ff2b323f317ae89e254ce87162d52a375

branches/stable/AUTHORS.txt

@@ -518,7 +518,6 @@ Luke Francl <[email protected]>
 Luke Metz <[email protected]>
 Luke Steensen <[email protected]>
 Luqman Aden <[email protected]>
-Łukasz Niemier <[email protected]>
 Magnus Auvinen <[email protected]>
 Mahmut Bulut <[email protected]>
 Makoto Nakashima <[email protected]>
@@ -998,4 +997,5 @@ xales <[email protected]>
 zofrex <[email protected]>
 zslayton <[email protected]>
 zzmp <[email protected]>
+Łukasz Niemier <[email protected]>
 克雷 <[email protected]>

branches/stable/configure

@@ -19,11 +19,6 @@ err() {
     exit 1
 }
 
-run() {
-    msg "$@"
-    "$@"
-}
-
 need_ok() {
     if [ $? -ne 0 ]
     then
@@ -41,7 +36,8 @@ need_cmd() {
 make_dir() {
     if [ ! -d $1 ]
     then
-        run mkdir -p $1
+        msg "mkdir -p $1"
+        mkdir -p $1
     fi
 }
 
@@ -50,7 +46,8 @@ copy_if_changed() {
     then
         msg "leaving $2 unchanged"
     else
-        run cp -f $1 $2
+        msg "cp $1 $2"
+        cp -f $1 $2
         chmod u-w $2 # make copied artifact read-only
     fi
 }
@@ -60,7 +57,8 @@ move_if_changed() {
     then
         msg "leaving $2 unchanged"
     else
-        run mv -f $1 $2
+        msg "mv $1 $2"
+        mv -f $1 $2
         chmod u-w $2 # make moved artifact read-only
     fi
 }
@@ -735,20 +733,6 @@ then
    probe CFG_JAVAC            javac
 fi
 
-# the valgrind rpass tests will fail if you don't have a valgrind, but they're
-# only disabled if you opt out.
-if [ -z "$CFG_VALGRIND" ]
-then
-    # If the user has explicitly asked for valgrind tests, then fail
-    if [ -n "$CFG_ENABLE_VALGRIND" ] && [ -n "$CFG_ENABLE_VALGRIND_PROVIDED" ]
-    then
-        err "No valgrind present, but valgrind tests explicitly requested"
-    else
-        CFG_DISABLE_VALGRIND_RPASS=1
-        putvar CFG_DISABLE_VALGRIND_RPASS
-    fi
-fi
-
 if [ ! -z "$CFG_GDB" ]
 then
     # Store GDB's version
@@ -860,7 +844,7 @@ then
     CFG_OSX_GCC_VERSION=$("$CFG_GCC" --version 2>&1 | grep "Apple LLVM version")
     if [ $? -eq 0 ]
     then
-        step_msg "on OS X >=10.9, forcing use of clang"
+        step_msg "on OS X 10.9, forcing use of clang"
         CFG_ENABLE_CLANG=1
     else
         if [ $("$CFG_GCC" --version 2>&1 | grep -c ' 4\.[0-6]') -ne 0 ]; then

branches/stable/mk/dist.mk

@@ -52,7 +52,6 @@ PKG_FILES := \
       doc                                      \
       driver                                   \
       etc                                      \
-      error-index-generator                    \
       $(foreach crate,$(CRATES),lib$(crate))   \
       libcollectionstest                       \
       libcoretest                              \

branches/stable/mk/main.mk

@@ -195,7 +195,6 @@ ifndef CFG_DISABLE_VALGRIND_RPASS
   $(info cfg: valgrind-rpass command set to $(CFG_VALGRIND))
   CFG_VALGRIND_RPASS :=$(CFG_VALGRIND)
 else
-  $(info cfg: disabling valgrind run-pass tests)
   CFG_VALGRIND_RPASS :=
 endif
 

branches/stable/src/compiletest/compiletest.rs

@@ -226,15 +226,15 @@ pub fn run_tests(config: &Config) {
         }
 
         // android debug-info test uses remote debugger
-        // so, we test 1 thread at once.
+        // so, we test 1 task at once.
         // also trying to isolate problems with adb_run_wrapper.sh ilooping
         env::set_var("RUST_TEST_THREADS","1");
     }
 
     match config.mode {
         DebugInfoLldb => {
             // Some older versions of LLDB seem to have problems with multiple
-            // instances running in parallel, so only run one test thread at a
+            // instances running in parallel, so only run one test task at a
             // time.
             env::set_var("RUST_TEST_THREADS", "1");
         }

branches/stable/src/doc/complement-design-faq.md

@@ -96,7 +96,7 @@ code should need to run is a stack.
 possibility is covered by the `match`, adding further variants to the `enum`
 in the future will prompt a compilation failure, rather than runtime panic.
 Second, it makes cost explicit. In general, the only safe way to have a
-non-exhaustive match would be to panic the thread if nothing is matched, though
+non-exhaustive match would be to panic the task if nothing is matched, though
 it could fall through if the type of the `match` expression is `()`. This sort
 of hidden cost and special casing is against the language's philosophy. It's
 easy to ignore certain cases by using the `_` wildcard:

branches/stable/src/doc/complement-lang-faq.md

@@ -62,15 +62,15 @@ Data values in the language can only be constructed through a fixed set of initi
 * There is no global inter-crate namespace; all name management occurs within a crate.
  * Using another crate binds the root of _its_ namespace into the user's namespace.
 
-## Why is panic unwinding non-recoverable within a thread? Why not try to "catch exceptions"?
+## Why is panic unwinding non-recoverable within a task? Why not try to "catch exceptions"?
 
-In short, because too few guarantees could be made about the dynamic environment of the catch block, as well as invariants holding in the unwound heap, to be able to safely resume; we believe that other methods of signalling and logging errors are more appropriate, with threads playing the role of a "hard" isolation boundary between separate heaps.
+In short, because too few guarantees could be made about the dynamic environment of the catch block, as well as invariants holding in the unwound heap, to be able to safely resume; we believe that other methods of signalling and logging errors are more appropriate, with tasks playing the role of a "hard" isolation boundary between separate heaps.
 
 Rust provides, instead, three predictable and well-defined options for handling any combination of the three main categories of "catch" logic:
 
 * Failure _logging_ is done by the integrated logging subsystem.
-* _Recovery_ after a panic is done by trapping a thread panic from _outside_
-  the thread, where other threads are known to be unaffected.
+* _Recovery_ after a panic is done by trapping a task panic from _outside_
+  the task, where other tasks are known to be unaffected.
 * _Cleanup_ of resources is done by RAII-style objects with destructors.
 
 Cleanup through RAII-style destructors is more likely to work than in catch blocks anyways, since it will be better tested (part of the non-error control paths, so executed all the time).
@@ -91,8 +91,8 @@ We don't know if there's an obvious, easy, efficient, stock-textbook way of supp
 
 There's a lot of debate on this topic; it's easy to find a proponent of default-sync or default-async communication, and there are good reasons for either. Our choice rests on the following arguments:
 
-* Part of the point of isolating threads is to decouple threads from one another, such that assumptions in one thread do not cause undue constraints (or bugs, if violated!) in another. Temporal coupling is as real as any other kind; async-by-default relaxes the default case to only _causal_ coupling.
-* Default-async supports buffering and batching communication, reducing the frequency and severity of thread-switching and inter-thread / inter-domain synchronization.
+* Part of the point of isolating tasks is to decouple tasks from one another, such that assumptions in one task do not cause undue constraints (or bugs, if violated!) in another. Temporal coupling is as real as any other kind; async-by-default relaxes the default case to only _causal_ coupling.
+* Default-async supports buffering and batching communication, reducing the frequency and severity of task-switching and inter-task / inter-domain synchronization.
 * Default-async with transmittable channels is the lowest-level building block on which more-complex synchronization topologies and strategies can be built; it is not clear to us that the majority of cases fit the 2-party full-synchronization pattern rather than some more complex multi-party or multi-stage scenario. We did not want to force all programs to pay for wiring the former assumption into all communications.
 
 ## Why are channels half-duplex (one-way)?

branches/stable/src/doc/grammar.md

@@ -329,7 +329,7 @@ view_item : extern_crate_decl | use_decl ;
 
 ```antlr
 extern_crate_decl : "extern" "crate" crate_name
-crate_name: ident | ( ident "as" ident )
+crate_name: ident | ( string_lit as ident )
 ```
 
 ##### Use declarations
@@ -789,8 +789,8 @@ bound := path | lifetime
 
 ### Boxes
 
-## Threads
+## Tasks
 
-### Communication between threads
+### Communication between tasks
 
-### Thread lifecycle
+### Task lifecycle

branches/stable/src/doc/reference.md

@@ -752,10 +752,11 @@ provided in the `extern_crate_decl`.
 The external crate is resolved to a specific `soname` at compile time, and a
 runtime linkage requirement to that `soname` is passed to the linker for
 loading at runtime. The `soname` is resolved at compile time by scanning the
-compiler's library path and matching the optional `crateid` provided against
-the `crateid` attributes that were declared on the external crate when it was
-compiled. If no `crateid` is provided, a default `name` attribute is assumed,
-equal to the `ident` given in the `extern_crate_decl`.
+compiler's library path and matching the optional `crateid` provided as a
+string literal against the `crateid` attributes that were declared on the
+external crate when it was compiled. If no `crateid` is provided, a default
+`name` attribute is assumed, equal to the `ident` given in the
+`extern_crate_decl`.
 
 Three examples of `extern crate` declarations:
 
@@ -2028,7 +2029,7 @@ makes it possible to declare these operations. For example, the `str` module
 in the Rust standard library defines the string equality function:
 
 ```{.ignore}
-#[lang = "str_eq"]
+#[lang="str_eq"]
 pub fn eq_slice(a: &str, b: &str) -> bool {
     // details elided
 }
@@ -3635,7 +3636,7 @@ that have since been removed):
 * ML Kit, Cyclone: region based memory management
 * Haskell (GHC): typeclasses, type families
 * Newsqueak, Alef, Limbo: channels, concurrency
-* Erlang: message passing, thread failure, ~~linked thread failure~~,
+* Erlang: message passing, task failure, ~~linked task failure~~,
   ~~lightweight concurrency~~
 * Swift: optional bindings
 * Scheme: hygienic macros

branches/stable/src/doc/style/errors/handling.md

@@ -1,7 +1,7 @@
 % Handling errors
 
-### Use thread isolation to cope with failure. [FIXME]
+### Use task isolation to cope with failure. [FIXME]
 
-> **[FIXME]** Explain how to isolate threads and detect thread failure for recovery.
+> **[FIXME]** Explain how to isolate tasks and detect task failure for recovery.
 
 ### Consuming `Result` [FIXME]

branches/stable/src/doc/style/errors/signaling.md

@@ -11,13 +11,13 @@ Errors fall into one of three categories:
 The basic principle of the convention is that:
 
 * Catastrophic errors and programming errors (bugs) can and should only be
-recovered at a *coarse grain*, i.e. a thread boundary.
+recovered at a *coarse grain*, i.e. a task boundary.
 * Obstructions preventing an operation should be reported at a maximally *fine
 grain* -- to the immediate invoker of the operation.
 
 ## Catastrophic errors
 
-An error is _catastrophic_ if there is no meaningful way for the current thread to
+An error is _catastrophic_ if there is no meaningful way for the current task to
 continue after the error occurs.
 
 Catastrophic errors are _extremely_ rare, especially outside of `libstd`.
@@ -28,7 +28,7 @@ Catastrophic errors are _extremely_ rare, especially outside of `libstd`.
 
 For errors like stack overflow, Rust currently aborts the process, but
 could in principle panic, which (in the best case) would allow
-reporting and recovery from a supervisory thread.
+reporting and recovery from a supervisory task.
 
 ## Contract violations
 
@@ -44,7 +44,7 @@ existing borrows have been relinquished.
 
 A contract violation is always a bug, and for bugs we follow the Erlang
 philosophy of "let it crash": we assume that software *will* have bugs, and we
-design coarse-grained thread boundaries to report, and perhaps recover, from these
+design coarse-grained task boundaries to report, and perhaps recover, from these
 bugs.
 
 ### Contract design

branches/stable/src/doc/style/ownership/builders.md

@@ -23,7 +23,7 @@ If `T` is such a data structure, consider introducing a `T` _builder_:
 4. The builder should provide one or more "_terminal_" methods for actually building a `T`.
 
 The builder pattern is especially appropriate when building a `T` involves side
-effects, such as spawning a thread or launching a process.
+effects, such as spawning a task or launching a process.
 
 In Rust, there are two variants of the builder pattern, differing in the
 treatment of ownership, as described below.
@@ -115,24 +115,24 @@ Sometimes builders must transfer ownership when constructing the final type
 `T`, meaning that the terminal methods must take `self` rather than `&self`:
 
 ```rust
-// A simplified excerpt from std::thread::Builder
+// A simplified excerpt from std::task::TaskBuilder
 
-impl ThreadBuilder {
-    /// Name the thread-to-be. Currently the name is used for identification
+impl TaskBuilder {
+    /// Name the task-to-be. Currently the name is used for identification
     /// only in failure messages.
-    pub fn named(mut self, name: String) -> ThreadBuilder {
+    pub fn named(mut self, name: String) -> TaskBuilder {
         self.name = Some(name);
         self
     }
 
-    /// Redirect thread-local stdout.
-    pub fn stdout(mut self, stdout: Box<Writer + Send>) -> ThreadBuilder {
+    /// Redirect task-local stdout.
+    pub fn stdout(mut self, stdout: Box<Writer + Send>) -> TaskBuilder {
         self.stdout = Some(stdout);
         //   ^~~~~~ this is owned and cannot be cloned/re-used
         self
     }
 
-    /// Creates and executes a new child thread.
+    /// Creates and executes a new child task.
     pub fn spawn(self, f: proc():Send) {
         // consume self
         ...
@@ -141,7 +141,7 @@ impl ThreadBuilder {
 ```
 
 Here, the `stdout` configuration involves passing ownership of a `Writer`,
-which must be transferred to the thread upon construction (in `spawn`).
+which must be transferred to the task upon construction (in `spawn`).
 
 When the terminal methods of the builder require ownership, there is a basic tradeoff:
 
@@ -158,17 +158,17 @@ builder methods for a consuming builder should take and returned an owned
 
 ```rust
 // One-liners
-ThreadBuilder::new().named("my_thread").spawn(proc() { ... });
+TaskBuilder::new().named("my_task").spawn(proc() { ... });
 
 // Complex configuration
-let mut thread = ThreadBuilder::new();
-thread = thread.named("my_thread_2"); // must re-assign to retain ownership
+let mut task = TaskBuilder::new();
+task = task.named("my_task_2"); // must re-assign to retain ownership
 
 if reroute {
-    thread = thread.stdout(mywriter);
+    task = task.stdout(mywriter);
 }
 
-thread.spawn(proc() { ... });
+task.spawn(proc() { ... });
 ```
 
 One-liners work as before, because ownership is threaded through each of the

branches/stable/src/doc/style/ownership/destructors.md

@@ -8,7 +8,7 @@ go out of scope.
 
 ### Destructors should not fail. [FIXME: needs RFC]
 
-Destructors are executed on thread failure, and in that context a failing
+Destructors are executed on task failure, and in that context a failing
 destructor causes the program to abort.
 
 Instead of failing in a destructor, provide a separate method for checking for

branches/stable/src/doc/style/style/comments.md

@@ -5,15 +5,15 @@
 Use line comments:
 
 ``` rust
-// Wait for the main thread to return, and set the process error code
+// Wait for the main task to return, and set the process error code
 // appropriately.
 ```
 
 Instead of:
 
 ``` rust
 /*
- * Wait for the main thread to return, and set the process error code
+ * Wait for the main task to return, and set the process error code
  * appropriately.
  */
 ```
@@ -55,7 +55,7 @@ For example:
 /// Sets up a default runtime configuration, given compiler-supplied arguments.
 ///
 /// This function will block until the entire pool of M:N schedulers has
-/// exited. This function also requires a local thread to be available.
+/// exited. This function also requires a local task to be available.
 ///
 /// # Arguments
 ///
@@ -64,7 +64,7 @@ For example:
 /// * `main` - The initial procedure to run inside of the M:N scheduling pool.
 ///            Once this procedure exits, the scheduling pool will begin to shut
 ///            down. The entire pool (and this function) will only return once
-///            all child threads have finished executing.
+///            all child tasks have finished executing.
 ///
 /// # Return value
 ///

branches/stable/src/doc/style/style/naming/containers.md

@@ -5,7 +5,7 @@ they enclose.  Accessor methods often have variants to access the data
 by value, by reference, and by mutable reference.
 
 In general, the `get` family of methods is used to access contained
-data without any risk of thread failure; they return `Option` as
+data without any risk of task failure; they return `Option` as
 appropriate. This name is chosen rather than names like `find` or
 `lookup` because it is appropriate for a wider range of container types.