---

yaml
---
r: 146803
b: refs/heads/try2
c: acca9e3
h: refs/heads/master
i:
  146801: 2370538
  146799: 87d8465
v: v3

Author: alexcrichton

[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: ca3274336e9d61b29f6862b4706a2a105a208f0a
+refs/heads/try2: acca9e3834842ee8d8104abe9b8b9bb88861793c
 refs/heads/dist-snap: ba4081a5a8573875fed17545846f6f6902c8ba8d
 refs/tags/release-0.2: c870d2dffb391e14efb05aa27898f1f6333a9596
 refs/tags/release-0.3: b5f0d0f648d9a6153664837026ba1be43d3e2503

branches/try2/configure

@@ -520,20 +520,14 @@ then
     fi
 fi
 
-BIN_SUF=
-if [ $CFG_OSTYPE = "pc-mingw32" ]
-then
-    BIN_SUF=.exe
-fi
-
 if [ ! -z "$CFG_ENABLE_LOCAL_RUST" ]
 then
-    if [ ! -f ${CFG_LOCAL_RUST_ROOT}/bin/rustc${BIN_SUF} ]
+    if [ ! -f ${CFG_LOCAL_RUST_ROOT}/bin/rustc ]
     then
         err "no local rust to use"
     else
-        LRV=`${CFG_LOCAL_RUST_ROOT}/bin/rustc${BIN_SUF} --version`
-        step_msg "using rustc at: ${CFG_LOCAL_RUST_ROOT} with version: $LRV"
+        LRV=`${CFG_LOCAL_RUST_ROOT}/bin/rustc --version`
+        step_msg "using rustc at: ${CFG_LOCAL_RUST_ROOT} with version: " $LRV
     fi
 fi
 

branches/try2/doc/rust.md

@@ -1131,8 +1131,9 @@ block.
 let fptr: extern "C" fn() -> ~[int] = new_vec;
 ~~~~
 
-Extern functions may be called directly from Rust code as Rust uses large,
-contiguous stack segments like C.
+Extern functions may be called from Rust code, but
+caution must be taken with respect to the size of the stack
+segment, just as when calling an extern function normally.
 
 ### Type definitions
 
@@ -2349,9 +2350,9 @@ Indices are zero-based, and may be of any integral type. Vector access
 is bounds-checked at run-time. When the check fails, it will put the
 task in a _failing state_.
 
-~~~~
+~~~~ {.xfail-test}
 # use std::task;
-# do task::spawn_unlinked {
+# do task::spawn {
 
 ([1, 2, 3, 4])[0];
 (["a", "b"])[10]; // fails
@@ -3596,9 +3597,9 @@ and releases them back to its environment when they are no longer needed.
 The default implementation of the service-provider interface
 consists of the C runtime functions `malloc` and `free`.
 
-The runtime memory-management system, in turn, supplies Rust tasks with
-facilities for allocating releasing stacks, as well as allocating and freeing
-heap data.
+The runtime memory-management system, in turn, supplies Rust tasks
+with facilities for allocating, extending and releasing stacks,
+as well as allocating and freeing heap data.
 
 ### Built in types
 
@@ -3761,6 +3762,7 @@ have come and gone during the course of Rust's development:
 
 Additional specific influences can be seen from the following languages:
 
+* The stack-growth implementation of Go.
 * The structural algebraic types and compilation manager of SML.
 * The attribute and assembly systems of C#.
 * The references and deterministic destructor system of C++.

branches/try2/doc/tutorial-tasks.md

@@ -402,22 +402,6 @@ freeing memory along the way---and then exits. Unlike exceptions in C++,
 exceptions in Rust are unrecoverable within a single task: once a task fails,
 there is no way to "catch" the exception.
 
-All tasks are, by default, _linked_ to each other. That means that the fates
-of all tasks are intertwined: if one fails, so do all the others.
-
-~~~{.xfail-test .linked-failure}
-# use std::task::spawn;
-# use std::task;
-# fn do_some_work() { loop { task::yield() } }
-# do task::try {
-// Create a child task that fails
-do spawn { fail!() }
-
-// This will also fail because the task we spawned failed
-do_some_work();
-# };
-~~~
-
 While it isn't possible for a task to recover from failure, tasks may notify
 each other of failure. The simplest way of handling task failure is with the
 `try` function, which is similar to `spawn`, but immediately blocks waiting
@@ -464,101 +448,7 @@ it trips, indicates an unrecoverable logic error); in other cases you
 might want to contain the failure at a certain boundary (perhaps a
 small piece of input from the outside world, which you happen to be
 processing in parallel, is malformed and its processing task can't
-proceed). Hence, you will need different _linked failure modes_.
-
-## Failure modes
-
-By default, task failure is _bidirectionally linked_, which means that if
-either task fails, it kills the other one.
-
-~~~{.xfail-test .linked-failure}
-# use std::task;
-# use std::comm::oneshot;
-# fn sleep_forever() { loop { let (p, c) = oneshot::<()>(); p.recv(); } }
-# do task::try {
-do spawn {
-    do spawn {
-        fail!();  // All three tasks will fail.
-    }
-    sleep_forever();  // Will get woken up by force, then fail
-}
-sleep_forever();  // Will get woken up by force, then fail
-# };
-~~~
-
-If you want parent tasks to be able to kill their children, but do not want a
-parent to fail automatically if one of its child task fails, you can call
-`task::spawn_supervised` for _unidirectionally linked_ failure. The
-function `task::try`, which we saw previously, uses `spawn_supervised`
-internally, with additional logic to wait for the child task to finish
-before returning. Hence:
-
-~~~{.xfail-test .linked-failure}
-# use std::comm::{stream, Chan, Port};
-# use std::comm::oneshot;
-# use std::task::{spawn, try};
-# use std::task;
-# fn sleep_forever() { loop { let (p, c) = oneshot::<()>(); p.recv(); } }
-# do task::try {
-let (receiver, sender): (Port<int>, Chan<int>) = stream();
-do spawn {  // Bidirectionally linked
-    // Wait for the supervised child task to exist.
-    let message = receiver.recv();
-    // Kill both it and the parent task.
-    assert!(message != 42);
-}
-do try {  // Unidirectionally linked
-    sender.send(42);
-    sleep_forever();  // Will get woken up by force
-}
-// Flow never reaches here -- parent task was killed too.
-# };
-~~~
-
-Supervised failure is useful in any situation where one task manages
-multiple fallible child tasks, and the parent task can recover
-if any child fails. On the other hand, if the _parent_ (supervisor) fails,
-then there is nothing the children can do to recover, so they should
-also fail.
-
-Supervised task failure propagates across multiple generations even if
-an intermediate generation has already exited:
-
-~~~{.xfail-test .linked-failure}
-# use std::task;
-# use std::comm::oneshot;
-# fn sleep_forever() { loop { let (p, c) = oneshot::<()>(); p.recv(); } }
-# fn wait_for_a_while() { for _ in range(0, 1000u) { task::yield() } }
-# do task::try::<int> {
-do task::spawn_supervised {
-    do task::spawn_supervised {
-        sleep_forever();  // Will get woken up by force, then fail
-    }
-    // Intermediate task immediately exits
-}
-wait_for_a_while();
-fail!();  // Will kill grandchild even if child has already exited
-# };
-~~~
-
-Finally, tasks can be configured to not propagate failure to each
-other at all, using `task::spawn_unlinked` for _isolated failure_.
-
-~~~{.xfail-test .linked-failure}
-# use std::task;
-# fn random() -> uint { 100 }
-# fn sleep_for(i: uint) { for _ in range(0, i) { task::yield() } }
-# do task::try::<()> {
-let (time1, time2) = (random(), random());
-do task::spawn_unlinked {
-    sleep_for(time2);  // Won't get forced awake
-    fail!();
-}
-sleep_for(time1);  // Won't get forced awake
-fail!();
-// It will take MAX(time1,time2) for the program to finish.
-# };
-~~~
+proceed).
 
 ## Creating a task with a bi-directional communication path
 

branches/try2/doc/tutorial.md

@@ -890,7 +890,9 @@ calling the destructor, and the owner determines whether the object is mutable.
 
 Ownership is recursive, so mutability is inherited recursively and a destructor
 destroys the contained tree of owned objects. Variables are top-level owners
-and destroy the contained object when they go out of scope.
+and destroy the contained object when they go out of scope. A box managed by
+the garbage collector starts a new ownership tree, and the destructor is called
+when it is collected.
 
 ~~~~
 // the struct owns the objects contained in the `x` and `y` fields
@@ -1007,6 +1009,51 @@ let mut s = r; // box becomes mutable
 let t = s; // box becomes immutable
 ~~~~
 
+# Managed boxes
+
+A managed box (`@`) is a heap allocation with the lifetime managed by a
+task-local garbage collector. It will be destroyed at some point after there
+are no references left to the box, no later than the end of the task. Managed
+boxes lack an owner, so they start a new ownership tree and don't inherit
+mutability. They do own the contained object, and mutability is defined by the
+type of the managed box (`@` or `@mut`). An object containing a managed box is
+not `Owned`, and can't be sent between tasks.
+
+~~~~
+let a = @5; // immutable
+
+let mut b = @5; // mutable variable, immutable box
+b = @10;
+
+let c = @mut 5; // immutable variable, mutable box
+*c = 10;
+
+let mut d = @mut 5; // mutable variable, mutable box
+*d += 5;
+d = @mut 15;
+~~~~
+
+A mutable variable and an immutable variable can refer to the same box, given
+that their types are compatible. Mutability of a box is a property of its type,
+however, so for example a mutable handle to an immutable box cannot be
+assigned a reference to a mutable box.
+
+~~~~
+let a = @1;     // immutable box
+let b = @mut 2; // mutable box
+
+let mut c : @int;       // declare a variable with type managed immutable int
+let mut d : @mut int;   // and one of type managed mutable int
+
+c = a;          // box type is the same, okay
+d = b;          // box type is the same, okay
+~~~~
+
+~~~~ {.xfail-test}
+// but b cannot be assigned to c, or a to d
+c = b;          // error
+~~~~
+
 # Borrowed pointers
 
 Rust's borrowed pointers are a general purpose reference type. In contrast with
@@ -1300,53 +1347,6 @@ defined in [`std::vec`] and [`std::str`].
 [`std::vec`]: std/vec/index.html
 [`std::str`]: std/str/index.html
 
-# Ownership escape hatches
-
-Ownership can cleanly describe tree-like data structures, and borrowed pointers provide non-owning
-references. However, more flexibility is often desired and Rust provides ways to escape from strict
-single parent ownership.
-
-The standard library provides the `std::rc::Rc` pointer type to express *shared ownership* over a
-reference counted box. As soon as all of the `Rc` pointers go out of scope, the box and the
-contained value are destroyed.
-
-~~~
-use std::rc::Rc;
-
-// A fixed-size array allocated in a reference-counted box
-let x = Rc::new([1, 2, 3, 4, 5, 6, 7, 8, 9, 10]);
-let y = x.clone(); // a new owner
-let z = x; // this moves `x` into `z`, rather than creating a new owner
-
-assert_eq!(*z.borrow(), [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]);
-
-// the variable is mutable, but not the contents of the box
-let mut a = Rc::new([10, 9, 8, 7, 6, 5, 4, 3, 2, 1]);
-a = z;
-~~~
-
-A garbage collected pointer is provided via `std::gc::Gc`, with a task-local garbage collector
-having ownership of the box. It allows the creation of cycles, and the individual `Gc` pointers do
-not have a destructor.
-
-~~~
-use std::gc::Gc;
-
-// A fixed-size array allocated in a garbage-collected box
-let x = Gc::new([1, 2, 3, 4, 5, 6, 7, 8, 9, 10]);
-let y = x; // does not perform a move, unlike with `Rc`
-let z = x;
-
-assert_eq!(*z.borrow(), [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]);
-~~~
-
-With shared ownership, mutability cannot be inherited so the boxes are always immutable. However,
-it's possible to use *dynamic* mutability via types like `std::cell::Cell` where freezing is handled
-via dynamic checks and can fail at runtime.
-
-The `Rc` and `Gc` types are not sendable, so they cannot be used to share memory between tasks. Safe
-immutable and mutable shared memory is provided by the `extra::arc` module.
-
 # Closures
 
 Named functions, like those we've seen so far, may not refer to local