---

yaml
---
r: 106120
b: refs/heads/auto
c: 068740b
h: refs/heads/master
v: v3

Author: alexcrichton

[refs]

@@ -13,7 +13,7 @@ refs/heads/try3: 9387340aab40a73e8424c48fd42f0c521a4875c0
 refs/tags/release-0.3.1: 495bae036dfe5ec6ceafd3312b4dca48741e845b
 refs/tags/release-0.4: e828ea2080499553b97dfe33b3f4d472b4562ad7
 refs/tags/release-0.5: 7e3bcfbf21278251ee936ad53e92e9b719702d73
-refs/heads/auto: 8cfef59cc0922f15979bf4e8a0b344cecfa8d9e2
+refs/heads/auto: 068740b3433099d148c8e2d4bcc9b25309f40701
 refs/heads/servo: af82457af293e2a842ba6b7759b70288da276167
 refs/tags/release-0.6: b4ebcfa1812664df5e142f0134a5faea3918544c
 refs/tags/0.1: b19db808c2793fe2976759b85a355c3ad8c8b336

branches/auto/src/compiletest/runtest.rs

@@ -32,7 +32,7 @@ use std::io;
 use std::os;
 use std::str;
 use std::task;
-use std::slice;
+use std::vec;
 
 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 = slice::from_elem(
+    let mut found_flags = vec::from_elem(
         expected_errors.len(), false);
 
     if proc_res.status.success() {

branches/auto/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 `slice::raw` module to manipulate Rust
+Wrapping the functions which expect buffers involves using the `vec::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 = slice::with_capacity(dstlen as uint);
+        let mut dst = vec::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 = slice::with_capacity(dstlen as uint);
+        let mut dst = vec::with_capacity(dstlen as uint);
         let pdst = dst.as_mut_ptr();
 
         if snappy_uncompress(psrc, srclen, pdst, &mut dstlen) == 0 {

branches/auto/src/doc/guide-tasks.md

@@ -255,10 +255,10 @@ might look like the example below.
 
 ~~~
 # use std::task::spawn;
-# use std::slice;
+# use std::vec;
 
 // Create a vector of ports, one for each child task
-let rxs = slice::from_fn(3, |init_val| {
+let rxs = vec::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::slice;
+# use std::vec;
 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 = slice::from_fn(1000, |ind| sync::Future::spawn( proc() { partial_sum(ind) }));
+    let mut futures = vec::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::slice;
+use std::vec;
 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 = slice::from_fn(1000000, |_| rand::random::<f64>());
+    let numbers = vec::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::slice;
+# use std::vec;
 # fn main() {
-# let numbers = slice::from_fn(1000000, |_| rand::random::<f64>());
+# let numbers = vec::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::slice;
+# use std::vec;
 # fn main() {
-# let numbers=slice::from_fn(1000000, |_| rand::random::<f64>());
+# let numbers=vec::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::slice;
+# use std::vec;
 # fn main() {
-# let numbers=slice::from_fn(1000000, |_| rand::random::<f64>());
+# let numbers=vec::from_fn(1000000, |_| rand::random::<f64>());
 # let numbers_arc=Arc::new(numbers);
 # let (tx, rx) = channel();
 # tx.send(numbers_arc.clone());

branches/auto/src/doc/guide-testing.md

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

branches/auto/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`, `share` and `pod`.
+  various kinds; lang items `send`, `freeze` and `pod`.
 - the marker types and variance indicators found in
   `std::kinds::markers`; lang items `covariant_type`,
-  `contravariant_lifetime`, `no_share_bound`, etc.
+  `contravariant_lifetime`, `no_freeze_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/auto/src/doc/rust.md

@@ -3136,12 +3136,8 @@ machine.
 
 The types `char` and `str` hold textual data.
 
-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 `char` is a Unicode character,
+represented as a 32-bit unsigned word holding a UCS-4 codepoint.
 
 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/auto/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 paragraph will be used as the "summary" of an item in the
+is that the first paragrah 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 hierarchy that one
+The web pages generated by rustdoc present the same logical heirarchy 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 code fences confuse sundown => indentation + comment to
+    # nested codefences 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 code fences confuse sundown => indentation + comment to
+    # nested codefences 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 code fences confuse sundown => indentation + comment to
+    # nested codefences 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 code fences confuse sundown => indentation + comment to
+    # nested codefences 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 actually being documented.
+    # // what's actualy 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 accommodate this,
+and this code often requires `use`-ing paths from the crate. To accomodate 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/auto/src/doc/tutorial.md

@@ -2095,10 +2095,6 @@ 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/auto/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 slice::ImmutableVector;
+    use vec::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 slice::ImmutableVector;
+    use vec::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 slice::ImmutableVector;\n");
+    f.write("    use vec::ImmutableVector;\n");
     f.write("""
     fn bsearch_table(c: char, r: &'static [(char, &'static [char])]) -> Option<&'static [char]> {
         use cmp::{Equal, Less, Greater};

branches/auto/src/libarena/lib.rs

@@ -42,7 +42,7 @@ use std::rc::Rc;
 use std::rt::global_heap;
 use std::intrinsics::{TyDesc, get_tydesc};
 use std::intrinsics;
-use std::slice;
+use std::vec;
 
 // 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 +111,7 @@ impl Arena {
 
 fn chunk(size: uint, is_pod: bool) -> Chunk {
     Chunk {
-        data: Rc::new(RefCell::new(slice::with_capacity(size))),
+        data: Rc::new(RefCell::new(vec::with_capacity(size))),
         fill: Cell::new(0u),
         is_pod: Cell::new(is_pod),
     }