---

yaml
---
r: 142973
b: refs/heads/try2
c: dfa5595
h: refs/heads/master
i:
  142971: ba4b859
v: v3

Author: Keegan McAllister

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

branches/try2/configure

@@ -372,7 +372,6 @@ opt optimize 1 "build optimized rust code"
 opt optimize-cxx 1 "build optimized C++ code"
 opt optimize-llvm 1 "build optimized LLVM"
 opt debug 0 "build with extra debug fun"
-opt ratchet-bench 0 "ratchet benchmarks"
 opt fast-make 0 "use .gitmodules as timestamp for submodule deps"
 opt manage-submodules 1 "let the build manage the git submodules"
 opt mingw-cross 0 "cross-compile for win32 using mingw"
@@ -750,18 +749,18 @@ then
     cd ${CFG_SRC_DIR}
 
     msg "git: submodule sync"
-    "${CFG_GIT}" submodule sync
+    "${CFG_GIT}" submodule --quiet sync
 
     msg "git: submodule update"
-    "${CFG_GIT}" submodule update --init
+    "${CFG_GIT}" submodule --quiet update --init
     need_ok "git failed"
 
     msg "git: submodule foreach sync"
-    "${CFG_GIT}" submodule foreach --recursive 'if test -e .gitmodules; then git submodule sync; fi'
+    "${CFG_GIT}" submodule --quiet foreach --recursive 'if test -e .gitmodules; then git submodule sync; fi'
     need_ok "git failed"
 
     msg "git: submodule foreach update"
-    "${CFG_GIT}" submodule update --init --recursive
+    "${CFG_GIT}" submodule --quiet update --init --recursive
     need_ok "git failed"
 
     # NB: this is just for the sake of getting the submodule SHA1 values
@@ -770,9 +769,9 @@ then
     "${CFG_GIT}" submodule status --recursive
 
     msg "git: submodule clobber"
-    "${CFG_GIT}" submodule foreach --recursive git clean -dxf
+    "${CFG_GIT}" submodule --quiet foreach --recursive git clean -dxf
     need_ok "git failed"
-    "${CFG_GIT}" submodule foreach --recursive git checkout .
+    "${CFG_GIT}" submodule --quiet foreach --recursive git checkout .
     need_ok "git failed"
 
     cd ${CFG_BUILD_DIR}

branches/try2/doc/rust.md

@@ -206,6 +206,7 @@ The keywords are the following strings:
 ~~~~~~~~ {.keyword}
 as
 break
+copy
 do
 else enum extern
 false fn for
@@ -442,7 +443,7 @@ Two examples of paths with type arguments:
 ~~~~
 # use std::hashmap::HashMap;
 # fn f() {
-# fn id<T>(t: T) -> T { t }
+# fn id<T:Copy>(t: T) -> T { t }
 type t = HashMap<int,~str>;  // Type arguments used in a type expression
 let x = id::<int>(10);         // Type arguments used in a call expression
 # }
@@ -906,10 +907,11 @@ example, `sys::size_of::<u32>() == 4`.
 
 Since a parameter type is opaque to the generic function, the set of
 operations that can be performed on it is limited. Values of parameter
-type can only be moved, not copied.
+type can always be moved, but they can only be copied when the
+parameter is given a [`Copy` bound](#type-kinds).
 
 ~~~~
-fn id<T>(x: T) -> T { x }
+fn id<T: Copy>(x: T) -> T { x }
 ~~~~
 
 Similarly, [trait](#traits) bounds can be specified for type
@@ -1122,41 +1124,6 @@ static bits_n_strings: BitsNStrings<'static> = BitsNStrings {
 };
 ~~~~
 
-#### Mutable statics
-
-If a static item is declared with the ```mut``` keyword, then it is allowed to
-be modified by the program. One of Rust's goals is to make concurrency bugs hard
-to run into, and this is obviously a very large source of race conditions or
-other bugs. For this reason, an ```unsafe``` block is required when either
-reading or writing a mutable static variable. Care should be taken to ensure
-that modifications to a mutable static are safe with respect to other tasks
-running in the same process.
-
-Mutable statics are still very useful, however. They can be used with C
-libraries and can also be bound from C libraries (in an ```extern``` block).
-
-~~~
-# fn atomic_add(_: &mut uint, _: uint) -> uint { 2 }
-
-static mut LEVELS: uint = 0;
-
-// This violates the idea of no shared state, and this doesn't internally
-// protect against races, so this function is `unsafe`
-unsafe fn bump_levels_unsafe1() -> uint {
-    let ret = LEVELS;
-    LEVELS += 1;
-    return ret;
-}
-
-// Assuming that we have an atomic_add function which returns the old value,
-// this function is "safe" but the meaning of the return value may not be what
-// callers expect, so it's still marked as `unsafe`
-unsafe fn bump_levels_unsafe2() -> uint {
-    return atomic_add(&mut LEVELS, 1);
-}
-
-~~~
-
 ### Traits
 
 A _trait_ describes a set of method types.
@@ -1552,6 +1519,8 @@ A complete list of the built-in language items follows:
 
 `const`
   : Cannot be mutated.
+`copy`
+  : Can be implicitly copied.
 `owned`
   : Are uniquely owned.
 `durable`
@@ -1618,8 +1587,7 @@ A complete list of the built-in language items follows:
 `check_not_borrowed`
   : Fail if a value has existing borrowed pointers to it.
 `strdup_uniq`
-  : Return a new unique string
-    containing a copy of the contents of a unique string.
+  : Return a new unique string containing a copy of the contents of a unique string.
 
 > **Note:** This list is likely to become out of date. We should auto-generate it
 > from `librustc/middle/lang_items.rs`.
@@ -1768,13 +1736,10 @@ A temporary's lifetime equals the largest lifetime of any borrowed pointer that
 
 #### Moved and copied types
 
-When a [local variable](#memory-slots) is used
-as an [rvalue](#lvalues-rvalues-and-temporaries)
-the variable will either be [moved](#move-expressions) or copied,
+When a [local variable](#memory-slots) is used as an [rvalue](#lvalues-rvalues-and-temporaries)
+the variable will either be [moved](#move-expressions) or [copied](#copy-expressions),
 depending on its type.
-For types that contain [owning pointers](#owning-pointers)
-or values that implement the special trait `Drop`,
-the variable is moved.
+For types that contain mutable fields or [owning pointers](#owning-pointers), the variable is moved.
 All other types are copied.
 
 
@@ -1953,9 +1918,9 @@ task in a _failing state_.
 
 ### Unary operator expressions
 
-Rust defines six symbolic unary operators.
-They are all written as prefix operators,
-before the expression they apply to.
+Rust defines six symbolic unary operators,
+in addition to the unary [copy](#unary-copy-expressions) and [move](#unary-move-expressions) operators.
+They are all written as prefix operators, before the expression they apply to.
 
 `-`
   : Negation. May only be applied to numeric types.
@@ -2154,6 +2119,60 @@ An example of a parenthesized expression:
 let x = (2 + 3) * 4;
 ~~~~
 
+### Unary copy expressions
+
+~~~~~~~~{.ebnf .gram}
+copy_expr : "copy" expr ;
+~~~~~~~~
+
+> **Note:** `copy` expressions are deprecated. It's preferable to use
+> the `Clone` trait and `clone()` method.
+
+A _unary copy expression_ consists of the unary `copy` operator applied to
+some argument expression.
+
+Evaluating a copy expression first evaluates the argument expression, then
+copies the resulting value, allocating any memory necessary to hold the new
+copy.
+
+[Managed boxes](#pointer-types) (type `@`) are, as usual, shallow-copied,
+as are raw and borrowed pointers.
+[Owned boxes](#pointer-types), [owned vectors](#vector-types) and similar owned types are deep-copied.
+
+Since the binary [assignment operator](#assignment-expressions) `=` performs a copy or move implicitly,
+the unary copy operator is typically only used to cause an argument to a function to be copied and passed by value.
+
+An example of a copy expression:
+
+~~~~
+fn mutate(mut vec: ~[int]) {
+   vec[0] = 10;
+}
+
+let v = ~[1,2,3];
+
+mutate(copy v);   // Pass a copy
+
+assert!(v[0] == 1); // Original was not modified
+~~~~
+
+### Unary move expressions
+
+~~~~~~~~{.ebnf .gram}
+move_expr : "move" expr ;
+~~~~~~~~
+
+A _unary move expression_ is similar to a [unary copy](#unary-copy-expressions) expression,
+except that it can only be applied to a [local variable](#memory-slots),
+and it performs a _move_ on its operand, rather than a copy.
+That is, the memory location denoted by its operand is de-initialized after evaluation,
+and the resulting value is a shallow copy of the operand,
+even if the operand is an [owning type](#type-kinds).
+
+
+> **Note:** In future versions of Rust, `move` may be removed as a separate operator;
+> moves are now [automatically performed](#moved-and-copied-types) for most cases `move` would be appropriate.
+
 
 ### Call expressions
 
@@ -2488,11 +2507,10 @@ match x {
 }
 ~~~~
 
-Patterns that bind variables
-default to binding to a copy or move of the matched value
+Patterns that bind variables default to binding to a copy or move of the matched value
 (depending on the matched value's type).
-This can be changed to bind to a borrowed pointer by
-using the ```ref``` keyword,
+This can be made explicit using the ```copy``` keyword,
+changed to bind to a borrowed pointer by using the ```ref``` keyword,
 or to a mutable borrowed pointer using ```ref mut```.
 
 A pattern that's just an identifier,
@@ -2878,18 +2896,16 @@ and the cast expression in `main`.
 Within the body of an item that has type parameter declarations, the names of its type parameters are types:
 
 ~~~~~~~
-fn map<A: Clone, B: Clone>(f: &fn(A) -> B, xs: &[A]) -> ~[B] {
-    if xs.len() == 0 {
-       return ~[];
-    }
-    let first: B = f(xs[0].clone());
-    let rest: ~[B] = map(f, xs.slice(1, xs.len()));
-    return ~[first] + rest;
+fn map<A: Copy, B: Copy>(f: &fn(A) -> B, xs: &[A]) -> ~[B] {
+   if xs.len() == 0 { return ~[]; }
+   let first: B = f(copy xs[0]);
+   let rest: ~[B] = map(f, xs.slice(1, xs.len()));
+   return ~[first] + rest;
 }
 ~~~~~~~
 
-Here, `first` has type `B`, referring to `map`'s `B` type parameter;
-and `rest` has type `~[B]`, a vector type with element type `B`.
+Here, `first` has type `B`, referring to `map`'s `B` type parameter; and `rest` has
+type `~[B]`, a vector type with element type `B`.
 
 ### Self types
 
@@ -2903,9 +2919,7 @@ trait Printable {
 }
 
 impl Printable for ~str {
-    fn make_string(&self) -> ~str {
-        (*self).clone()
-    }
+  fn make_string(&self) -> ~str { copy *self }
 }
 ~~~~~~~~
 
@@ -2919,29 +2933,23 @@ The kinds are:
 
 `Freeze`
   : Types of this kind are deeply immutable;
-    they contain no mutable memory locations
-    directly or indirectly via pointers.
+    they contain no mutable memory locations directly or indirectly via pointers.
 `Send`
   : Types of this kind can be safely sent between tasks.
     This kind includes scalars, owning pointers, owned closures, and
-    structural types containing only other owned types.
-    All `Send` types are `'static`.
-`'static`
-  : Types of this kind do not contain any borrowed pointers;
-    this can be a useful guarantee for code
-    that breaks borrowing assumptions
-    using [`unsafe` operations](#unsafe-functions).
+    structural types containing only other owned types. All `Send` types are `Static`.
+`Copy`
+  : This kind includes all types that can be copied. All types with
+    sendable kind are copyable, as are managed boxes, managed closures,
+    trait types, and structural types built out of these.
+    Types with destructors (types that implement `Drop`) can not implement `Copy`.
 `Drop`
-  : This is not strictly a kind,
-    but its presence interacts with kinds:
-    the `Drop` trait provides a single method `drop`
-    that takes no parameters,
-    and is run when values of the type are dropped.
-    Such a method is called a "destructor",
-    and are always executed in "top-down" order:
-    a value is completely destroyed
-    before any of the values it owns run their destructors.
-    Only `Send` types can implement `Drop`.
+  : This is not strictly a kind, but its presence interacts with kinds: the `Drop`
+    trait provides a single method `drop` that takes no parameters, and is run
+    when values of the type are dropped. Such a method is called a "destructor",
+    and are always executed in "top-down" order: a value is completely destroyed
+    before any of the values it owns run their destructors. Only `Send` types
+    that do not implement `Copy` can implement `Drop`.
 
 _Default_
   : Types with destructors, closure environments,
@@ -2954,15 +2962,30 @@ Kinds can be supplied as _bounds_ on type parameters, like traits,
 in which case the parameter is constrained to types satisfying that kind.
 
 By default, type parameters do not carry any assumed kind-bounds at all.
-When instantiating a type parameter,
-the kind bounds on the parameter are checked
-to be the same or narrower than the kind
-of the type that it is instantiated with.
 
-Sending operations are not part of the Rust language,
-but are implemented in the library.
-Generic functions that send values
-bound the kind of these values to sendable.
+Any operation that causes a value to be copied requires the type of that value to be of copyable kind,
+so the `Copy` bound is frequently required on function type parameters.
+For example, this is not a valid program:
+
+~~~~{.xfail-test}
+fn box<T>(x: T) -> @T { @x }
+~~~~
+
+Putting `x` into a managed box involves copying, and the `T` parameter has the default (non-copyable) kind.
+To change that, a bound is declared:
+
+~~~~
+fn box<T: Copy>(x: T) -> @T { @x }
+~~~~
+
+Calling this second version of `box` on a noncopyable type is not
+allowed. When instantiating a type parameter, the kind bounds on the
+parameter are checked to be the same or narrower than the kind of the
+type that it is instantiated with.
+
+Sending operations are not part of the Rust language, but are
+implemented in the library. Generic functions that send values bound
+the kind of these values to sendable.
 
 # Memory and concurrency models
 
@@ -3070,7 +3093,9 @@ managed box value makes a shallow copy of the pointer (optionally incrementing
 a reference count, if the managed box is implemented through
 reference-counting).
 
-Owned box values exist in 1:1 correspondence with their heap allocation.
+Owned box values exist in 1:1 correspondence with their heap allocation;
+copying an owned box value makes a deep copy of the heap allocation and
+produces a pointer to the new allocation.
 
 An example of constructing one managed box type and value, and one owned box
 type and value: