---

yaml
---
r: 142975
b: refs/heads/try2
c: 91ebfbb
h: refs/heads/master
i:
  142973: b11122d
  142971: ba4b859
  142967: 21cd97f
  142959: 64b9d68
  142943: d7d5758
  142911: b27fb10
  142847: c202baf
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: 2d82d9364c194d0ee6c46c378dfdb4d8b04a581a
+refs/heads/try2: 91ebfbb9592a2262c62c684a5a2431111c987b1e
 refs/heads/dist-snap: ba4081a5a8573875fed17545846f6f6902c8ba8d
 refs/tags/release-0.2: c870d2dffb391e14efb05aa27898f1f6333a9596
 refs/tags/release-0.3: b5f0d0f648d9a6153664837026ba1be43d3e2503

branches/try2/configure

@@ -372,6 +372,7 @@ 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"
@@ -749,18 +750,18 @@ then
     cd ${CFG_SRC_DIR}
 
     msg "git: submodule sync"
-    "${CFG_GIT}" submodule --quiet sync
+    "${CFG_GIT}" submodule sync
 
     msg "git: submodule update"
-    "${CFG_GIT}" submodule --quiet update --init
+    "${CFG_GIT}" submodule update --init
     need_ok "git failed"
 
     msg "git: submodule foreach sync"
-    "${CFG_GIT}" submodule --quiet foreach --recursive 'if test -e .gitmodules; then git submodule sync; fi'
+    "${CFG_GIT}" submodule foreach --recursive 'if test -e .gitmodules; then git submodule sync; fi'
     need_ok "git failed"
 
     msg "git: submodule foreach update"
-    "${CFG_GIT}" submodule --quiet update --init --recursive
+    "${CFG_GIT}" submodule update --init --recursive
     need_ok "git failed"
 
     # NB: this is just for the sake of getting the submodule SHA1 values
@@ -769,9 +770,9 @@ then
     "${CFG_GIT}" submodule status --recursive
 
     msg "git: submodule clobber"
-    "${CFG_GIT}" submodule --quiet foreach --recursive git clean -dxf
+    "${CFG_GIT}" submodule foreach --recursive git clean -dxf
     need_ok "git failed"
-    "${CFG_GIT}" submodule --quiet foreach --recursive git checkout .
+    "${CFG_GIT}" submodule foreach --recursive git checkout .
     need_ok "git failed"
 
     cd ${CFG_BUILD_DIR}

branches/try2/doc/rust.md

@@ -206,7 +206,6 @@ The keywords are the following strings:
 ~~~~~~~~ {.keyword}
 as
 break
-copy
 do
 else enum extern
 false fn for
@@ -443,7 +442,7 @@ Two examples of paths with type arguments:
 ~~~~
 # use std::hashmap::HashMap;
 # fn f() {
-# fn id<T:Copy>(t: T) -> T { t }
+# fn id<T>(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
 # }
@@ -907,11 +906,10 @@ 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 always be moved, but they can only be copied when the
-parameter is given a [`Copy` bound](#type-kinds).
+type can only be moved, not copied.
 
 ~~~~
-fn id<T: Copy>(x: T) -> T { x }
+fn id<T>(x: T) -> T { x }
 ~~~~
 
 Similarly, [trait](#traits) bounds can be specified for type
@@ -1124,6 +1122,41 @@ 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.
@@ -1519,8 +1552,6 @@ A complete list of the built-in language items follows:
 
 `const`
   : Cannot be mutated.
-`copy`
-  : Can be implicitly copied.
 `owned`
   : Are uniquely owned.
 `durable`
@@ -1587,7 +1618,8 @@ 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`.
@@ -1736,10 +1768,13 @@ 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](#copy-expressions),
+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,
 depending on its type.
-For types that contain mutable fields or [owning pointers](#owning-pointers), the variable is moved.
+For types that contain [owning pointers](#owning-pointers)
+or values that implement the special trait `Drop`,
+the variable is moved.
 All other types are copied.
 
 
@@ -1918,9 +1953,9 @@ task in a _failing state_.
 
 ### Unary operator expressions
 
-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.
+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.
@@ -2119,60 +2154,6 @@ 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
 
@@ -2507,10 +2488,11 @@ 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 made explicit using the ```copy``` keyword,
-changed to bind to a borrowed pointer by using the ```ref``` keyword,
+This can be 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,
@@ -2896,16 +2878,18 @@ 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: 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;
+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;
 }
 ~~~~~~~
 
-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
 
@@ -2919,7 +2903,9 @@ trait Printable {
 }
 
 impl Printable for ~str {
-  fn make_string(&self) -> ~str { copy *self }
+    fn make_string(&self) -> ~str {
+        (*self).clone()
+    }
 }
 ~~~~~~~~
 
@@ -2933,23 +2919,29 @@ 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`.
-`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`.
+    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).
 `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`.
+  : 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`.
 
 _Default_
   : Types with destructors, closure environments,
@@ -2962,30 +2954,15 @@ 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.
 
-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.
+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
 
@@ -3093,9 +3070,7 @@ 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;
-copying an owned box value makes a deep copy of the heap allocation and
-produces a pointer to the new allocation.
+Owned box values exist in 1:1 correspondence with their heap allocation.
 
 An example of constructing one managed box type and value, and one owned box
 type and value: