---

yaml
---
r: 104991
b: refs/heads/snap-stage3
c: 6eae7df
h: refs/heads/master
i:
  104989: 57659b5
  104987: a956ca9
  104983: c2fbbe8
  104975: 669aa29
  104959: e1f0ef3
v: v3

Author: bors

[refs]

@@ -1,7 +1,7 @@
 ---
 refs/heads/master: 62f1d68439dcfd509eaca29887afa97f22938373
 refs/heads/snap-stage1: e33de59e47c5076a89eadeb38f4934f58a3618a6
-refs/heads/snap-stage3: 0de6441aa928446e9e9c4c9a903dcb66a3145c1a
+refs/heads/snap-stage3: 6eae7df43cd21b76fe91eeaf6ef2af9bd2a8fafc
 refs/heads/try: db814977d07bd798feb24f6b74c00800ef458a13
 refs/tags/release-0.1: 1f5c5126e96c79d22cb7862f75304136e204f105
 refs/heads/ndm: f3868061cd7988080c30d6d5bf352a5a5fe2460b

branches/snap-stage3/src/compiletest/compiletest.rs

@@ -13,7 +13,6 @@
 
 #[allow(non_camel_case_types)];
 #[deny(warnings)];
-#[allow(deprecated_owned_vector)];
 
 extern crate test;
 extern crate getopts;

branches/snap-stage3/src/compiletest/runtest.rs

@@ -32,7 +32,7 @@ use std::io;
 use std::os;
 use std::str;
 use std::task;
-use std::vec;
+use std::slice;
 
 use test::MetricMap;
 
@@ -500,7 +500,7 @@ fn check_expected_errors(expected_errors: ~[errors::ExpectedError],
                          proc_res: &ProcRes) {
 
     // true if we found the error in question
-    let mut found_flags = vec::from_elem(
+    let mut found_flags = slice::from_elem(
         expected_errors.len(), false);
 
     if proc_res.status.success() {

branches/snap-stage3/src/doc/guide-ffi.md

@@ -71,7 +71,7 @@ The raw C API needs to be wrapped to provide memory safety and make use of highe
 like vectors. A library can choose to expose only the safe, high-level interface and hide the unsafe
 internal details.
 
-Wrapping the functions which expect buffers involves using the `vec::raw` module to manipulate Rust
+Wrapping the functions which expect buffers involves using the `slice::raw` module to manipulate Rust
 vectors as pointers to memory. Rust's vectors are guaranteed to be a contiguous block of memory. The
 length is number of elements currently contained, and the capacity is the total size in elements of
 the allocated memory. The length is less than or equal to the capacity.
@@ -103,7 +103,7 @@ pub fn compress(src: &[u8]) -> ~[u8] {
         let psrc = src.as_ptr();
 
         let mut dstlen = snappy_max_compressed_length(srclen);
-        let mut dst = vec::with_capacity(dstlen as uint);
+        let mut dst = slice::with_capacity(dstlen as uint);
         let pdst = dst.as_mut_ptr();
 
         snappy_compress(psrc, srclen, pdst, &mut dstlen);
@@ -125,7 +125,7 @@ pub fn uncompress(src: &[u8]) -> Option<~[u8]> {
         let mut dstlen: size_t = 0;
         snappy_uncompressed_length(psrc, srclen, &mut dstlen);
 
-        let mut dst = vec::with_capacity(dstlen as uint);
+        let mut dst = slice::with_capacity(dstlen as uint);
         let pdst = dst.as_mut_ptr();
 
         if snappy_uncompress(psrc, srclen, pdst, &mut dstlen) == 0 {

branches/snap-stage3/src/doc/guide-tasks.md

@@ -255,10 +255,10 @@ might look like the example below.
 
 ~~~
 # use std::task::spawn;
-# use std::vec;
+# use std::slice;
 
 // Create a vector of ports, one for each child task
-let rxs = vec::from_fn(3, |init_val| {
+let rxs = slice::from_fn(3, |init_val| {
     let (tx, rx) = channel();
     spawn(proc() {
         tx.send(some_expensive_computation(init_val));
@@ -304,7 +304,7 @@ be distributed on the available cores.
 
 ~~~
 # extern crate sync;
-# use std::vec;
+# use std::slice;
 fn partial_sum(start: uint) -> f64 {
     let mut local_sum = 0f64;
     for num in range(start*100000, (start+1)*100000) {
@@ -314,7 +314,7 @@ fn partial_sum(start: uint) -> f64 {
 }
 
 fn main() {
-    let mut futures = vec::from_fn(1000, |ind| sync::Future::spawn( proc() { partial_sum(ind) }));
+    let mut futures = slice::from_fn(1000, |ind| sync::Future::spawn( proc() { partial_sum(ind) }));
 
     let mut final_res = 0f64;
     for ft in futures.mut_iter()  {
@@ -342,15 +342,15 @@ a single large vector of floats. Each task needs the full vector to perform its
 extern crate rand;
 extern crate sync;
 
-use std::vec;
+use std::slice;
 use sync::Arc;
 
 fn pnorm(nums: &~[f64], p: uint) -> f64 {
     nums.iter().fold(0.0, |a,b| a+(*b).powf(&(p as f64)) ).powf(&(1.0 / (p as f64)))
 }
 
 fn main() {
-    let numbers = vec::from_fn(1000000, |_| rand::random::<f64>());
+    let numbers = slice::from_fn(1000000, |_| rand::random::<f64>());
     let numbers_arc = Arc::new(numbers);
 
     for num in range(1u, 10) {
@@ -374,9 +374,9 @@ created by the line
 # extern crate sync;
 # extern crate rand;
 # use sync::Arc;
-# use std::vec;
+# use std::slice;
 # fn main() {
-# let numbers = vec::from_fn(1000000, |_| rand::random::<f64>());
+# let numbers = slice::from_fn(1000000, |_| rand::random::<f64>());
 let numbers_arc=Arc::new(numbers);
 # }
 ~~~
@@ -387,9 +387,9 @@ and a clone of it is sent to each task
 # extern crate sync;
 # extern crate rand;
 # use sync::Arc;
-# use std::vec;
+# use std::slice;
 # fn main() {
-# let numbers=vec::from_fn(1000000, |_| rand::random::<f64>());
+# let numbers=slice::from_fn(1000000, |_| rand::random::<f64>());
 # let numbers_arc = Arc::new(numbers);
 # let (tx, rx) = channel();
 tx.send(numbers_arc.clone());
@@ -404,9 +404,9 @@ Each task recovers the underlying data by
 # extern crate sync;
 # extern crate rand;
 # use sync::Arc;
-# use std::vec;
+# use std::slice;
 # fn main() {
-# let numbers=vec::from_fn(1000000, |_| rand::random::<f64>());
+# let numbers=slice::from_fn(1000000, |_| rand::random::<f64>());
 # let numbers_arc=Arc::new(numbers);
 # let (tx, rx) = channel();
 # tx.send(numbers_arc.clone());

branches/snap-stage3/src/doc/guide-testing.md

@@ -188,18 +188,18 @@ For example:
 # #[allow(unused_imports)];
 extern crate test;
 
-use std::vec;
+use std::slice;
 use test::BenchHarness;
 
 #[bench]
 fn bench_sum_1024_ints(b: &mut BenchHarness) {
-    let v = vec::from_fn(1024, |n| n);
+    let v = slice::from_fn(1024, |n| n);
     b.iter(|| {v.iter().fold(0, |old, new| old + *new);} );
 }
 
 #[bench]
 fn initialise_a_vector(b: &mut BenchHarness) {
-    b.iter(|| {vec::from_elem(1024, 0u64);} );
+    b.iter(|| {slice::from_elem(1024, 0u64);} );
     b.bytes = 1024 * 8;
 }
 

branches/snap-stage3/src/doc/guide-unsafe.md

@@ -595,10 +595,10 @@ Other features provided by lang items include:
 - stack unwinding and general failure; the `eh_personality`, `fail_`
   and `fail_bounds_checks` lang items.
 - the traits in `std::kinds` used to indicate types that satisfy
-  various kinds; lang items `send`, `freeze` and `pod`.
+  various kinds; lang items `send`, `share` and `pod`.
 - the marker types and variance indicators found in
   `std::kinds::markers`; lang items `covariant_type`,
-  `contravariant_lifetime`, `no_freeze_bound`, etc.
+  `contravariant_lifetime`, `no_share_bound`, etc.
 
 Lang items are loaded lazily by the compiler; e.g. if one never uses
 `~` then there is no need to define functions for `exchange_malloc`

branches/snap-stage3/src/doc/rust.md

@@ -3136,8 +3136,12 @@ machine.
 
 The types `char` and `str` hold textual data.
 
-A value of type `char` is a Unicode character,
-represented as a 32-bit unsigned word holding a UCS-4 codepoint.
+A value of type `char` is a [Unicode scalar value](
+http://www.unicode.org/glossary/#unicode_scalar_value)
+(ie. a code point that is not a surrogate),
+represented as a 32-bit unsigned word in the 0x0000 to 0xD7FF 
+or 0xE000 to 0x10FFFF range.
+A `[char]` vector is effectively an UCS-4 / UTF-32 string.
 
 A value of type `str` is a Unicode string,
 represented as a vector of 8-bit unsigned bytes holding a sequence of UTF-8 codepoints.

branches/snap-stage3/src/doc/rustdoc.md

@@ -43,7 +43,7 @@ pub fn recalibrate() {
 Doc comments are markdown, and are currently parsed with the
 [sundown][sundown] library. rustdoc does not yet do any fanciness such as
 referencing other items inline, like javadoc's `@see`. One exception to this
-is that the first paragrah will be used as the "summary" of an item in the
+is that the first paragraph will be used as the "summary" of an item in the
 generated documentation:
 
 ~~~
@@ -79,11 +79,11 @@ rustdoc can also generate JSON, for consumption by other tools, with
 
 # Using the Documentation
 
-The web pages generated by rustdoc present the same logical heirarchy that one
+The web pages generated by rustdoc present the same logical hierarchy that one
 writes a library with. Every kind of item (function, struct, etc) has its own
 color, and one can always click on a colored type to jump to its
 documentation. There is a search bar at the top, which is powered by some
-javascript and a statically-generated search index. No special web server is
+JavaScript and a statically-generated search index. No special web server is
 required for the search.
 
 [sundown]: https://github.com/vmg/sundown/
@@ -108,7 +108,7 @@ code, the `ignore` string can be added to the three-backtick form of markdown
 code block.
 
     /**
-    # nested codefences confuse sundown => indentation + comment to
+    # nested code fences confuse sundown => indentation + comment to
     #  avoid failing tests
     ```
     // This is a testable code block
@@ -126,7 +126,7 @@ You can specify that the test's execution should fail with the `should_fail`
 directive.
 
     /**
-    # nested codefences confuse sundown => indentation + comment to
+    # nested code fences confuse sundown => indentation + comment to
     #  avoid failing tests
     ```should_fail
     // This code block is expected to generate a failure when run
@@ -138,7 +138,7 @@ You can specify that the code block should be compiled but not run with the
 `no_run` directive.
 
     /**
-    # nested codefences confuse sundown => indentation + comment to
+    # nested code fences confuse sundown => indentation + comment to
     #  avoid failing tests
     ```no_run
     // This code will be compiled but not executed
@@ -153,7 +153,7 @@ testing the code block (NB. the space after the `#` is required, so
 that one can still write things like `#[deriving(Eq)]`).
 
     /**
-    # nested codefences confuse sundown => indentation + comment to
+    # nested code fences confuse sundown => indentation + comment to
     #  avoid failing tests
     ```rust
     # /!\ The three following lines are comments, which are usually stripped off by
@@ -162,7 +162,7 @@ that one can still write things like `#[deriving(Eq)]`).
     # these first five lines but a non breakable one.
     #
     # // showing 'fib' in this documentation would just be tedious and detracts from
-    # // what's actualy being documented.
+    # // what's actually being documented.
     # fn fib(n: int) { n + 2 }
 
     do spawn { fib(200); }
@@ -190,7 +190,7 @@ $ rustdoc --test lib.rs --test-args '--help'
 ~~~
 
 When testing a library, code examples will often show how functions are used,
-and this code often requires `use`-ing paths from the crate. To accomodate this,
+and this code often requires `use`-ing paths from the crate. To accommodate this,
 rustdoc will implicitly add `extern crate <crate>;` where `<crate>` is the name of
 the crate being tested to the top of each code example. This means that rustdoc
 must be able to find a compiled version of the library crate being tested. Extra

branches/snap-stage3/src/doc/tutorial.md

@@ -2095,6 +2095,10 @@ and may not be overridden:
 Types are sendable
 unless they contain managed boxes, managed closures, or references.
 
+* `Share` - Types that are *threadsafe*
+These are types that are safe to be used across several threads with access to
+a `&T` pointer. `MutexArc` is an example of a *sharable* type with internal mutable data.
+
 * `Freeze` - Constant (immutable) types.
 These are types that do not contain anything intrinsically mutable.
 Intrinsically mutable values include `Cell` in the standard library.

branches/snap-stage3/src/etc/unicode.py

@@ -162,7 +162,7 @@ def emit_bsearch_range_table(f):
     f.write("""
 fn bsearch_range_table(c: char, r: &'static [(char,char)]) -> bool {
     use cmp::{Equal, Less, Greater};
-    use vec::ImmutableVector;
+    use slice::ImmutableVector;
     use option::None;
     r.bsearch(|&(lo,hi)| {
         if lo <= c && c <= hi { Equal }
@@ -200,7 +200,7 @@ def emit_conversions_module(f, lowerupper, upperlower):
     f.write("pub mod conversions {\n")
     f.write("""
     use cmp::{Equal, Less, Greater};
-    use vec::ImmutableVector;
+    use slice::ImmutableVector;
     use tuple::Tuple2;
     use option::{Option, Some, None};
 
@@ -264,7 +264,7 @@ def emit_decomp_module(f, canon, compat, combine):
     f.write("pub mod decompose {\n");
     f.write("    use option::Option;\n");
     f.write("    use option::{Some, None};\n");
-    f.write("    use vec::ImmutableVector;\n");
+    f.write("    use slice::ImmutableVector;\n");
     f.write("""
     fn bsearch_table(c: char, r: &'static [(char, &'static [char])]) -> Option<&'static [char]> {
         use cmp::{Equal, Less, Greater};

branches/snap-stage3/src/libarena/lib.rs

@@ -24,7 +24,6 @@
       html_root_url = "http://static.rust-lang.org/doc/master")];
 #[allow(missing_doc)];
 #[feature(managed_boxes)];
-#[allow(deprecated_owned_vector)];
 
 extern crate collections;
 
@@ -42,7 +41,7 @@ use std::rc::Rc;
 use std::rt::global_heap;
 use std::intrinsics::{TyDesc, get_tydesc};
 use std::intrinsics;
-use std::vec;
+use std::slice;
 
 // The way arena uses arrays is really deeply awful. The arrays are
 // allocated, and have capacities reserved, but the fill for the array
@@ -111,7 +110,7 @@ impl Arena {
 
 fn chunk(size: uint, is_pod: bool) -> Chunk {
     Chunk {
-        data: Rc::new(RefCell::new(vec::with_capacity(size))),
+        data: Rc::new(RefCell::new(slice::with_capacity(size))),
         fill: Cell::new(0u),
         is_pod: Cell::new(is_pod),
     }