---

yaml
---
r: 195540
b: refs/heads/master
c: 39aa668
h: refs/heads/master
v: v3

Author: kvark

[refs]

@@ -1,5 +1,5 @@
 ---
-refs/heads/master: 02b38a2497c48c6195cdde4934ea08753f5b5539
+refs/heads/master: 39aa668a01fb671cff382a8237ec3993c9cc4c33
 refs/heads/snap-stage1: e33de59e47c5076a89eadeb38f4934f58a3618a6
 refs/heads/snap-stage3: b3317d68910900f135f9f38e43a7a699bc736b4a
 refs/heads/try: 961e0358e1a5c0faaef606e31e9965742c1643bf

trunk/src/compiletest/compiletest.rs

@@ -18,6 +18,7 @@
 #![feature(std_misc)]
 #![feature(test)]
 #![feature(path_ext)]
+#![feature(convert)]
 #![feature(str_char)]
 
 #![deny(warnings)]

trunk/src/doc/reference.md

@@ -977,13 +977,17 @@ An example of `use` declarations:
 
 ```
 # #![feature(core)]
+use std::iter::range_step;
 use std::option::Option::{Some, None};
 use std::collections::hash_map::{self, HashMap};
 
 fn foo<T>(_: T){}
 fn bar(map1: HashMap<String, usize>, map2: hash_map::HashMap<String, usize>){}
 
 fn main() {
+    // Equivalent to 'std::iter::range_step(0, 10, 2);'
+    range_step(0, 10, 2);
+
     // Equivalent to 'foo(vec![std::option::Option::Some(1.0f64),
     // std::option::Option::None]);'
     foo(vec![Some(1.0f64), None]);

trunk/src/doc/trpl/SUMMARY.md

@@ -42,6 +42,5 @@
     * [Intrinsics](intrinsics.md)
     * [Lang items](lang-items.md)
     * [Link args](link-args.md)
-    * [Benchmark Tests](benchmark-tests.md)
 * [Conclusion](conclusion.md)
 * [Glossary](glossary.md)

trunk/src/doc/trpl/benchmark-tests.md

@@ -280,15 +280,13 @@ it returns an `Result<T, E>`, and because this is just an example, we `unwrap()`
 it to get a reference to the data. Real code would have more robust error handling
 here. We're then free to mutate it, since we have the lock.
 
-Lastly, while the threads are running, we wait on a short timer. But
-this is not ideal: we may have picked a reasonable amount of time to
-wait but it's more likely we'll either be waiting longer than
-necessary or not long enough, depending on just how much time the
-threads actually take to finish computing when the program runs.
-
-A more precise alternative to the timer would be to use one of the
-mechanisms provided by the Rust standard library for synchronizing
-threads with each other. Let's talk about one of them: channels.
+This timer bit is a bit awkward, however. We have picked a reasonable amount of
+time to wait, but it's entirely possible that we've picked too high, and that
+we could be taking less time. It's also possible that we've picked too low,
+and that we aren't actually finishing this computation.
+
+Rust's standard library provides a few more mechanisms for two threads to
+synchronize with each other. Let's talk about one: channels.
 
 ## Channels
 

trunk/src/doc/trpl/concurrency.md

@@ -243,12 +243,11 @@ for num in nums.iter() {
 ```
 
 These two basic iterators should serve you well. There are some more
-advanced iterators, including ones that are infinite. Like using range syntax
-and `step_by`:
+advanced iterators, including ones that are infinite. Like `count`:
 
 ```rust
-# #![feature(step_by)]
-(1..).step_by(5);
+# #![feature(core)]
+std::iter::count(1, 5);
 ```
 
 This iterator counts up from one, adding five each time. It will give
@@ -293,11 +292,11 @@ just use `for` instead.
 There are tons of interesting iterator adapters. `take(n)` will return an
 iterator over the next `n` elements of the original iterator, note that this
 has no side effect on the original iterator. Let's try it out with our infinite
-iterator from before:
+iterator from before, `count()`:
 
 ```rust
-# #![feature(step_by)]
-for i in (1..).step_by(5).take(5) {
+# #![feature(core)]
+for i in std::iter::count(1, 5).take(5) {
     println!("{}", i);
 }
 ```

trunk/src/doc/trpl/iterators.md

@@ -37,7 +37,7 @@ number of elements.
 
 ```rust
 let x: Vec<u32> = vec![1, 2, 3];
-# assert_eq!(x, [1, 2, 3]);
+# assert_eq!(&[1,2,3], &x);
 ```
 
 This can't be an ordinary function, because it takes any number of arguments.
@@ -51,7 +51,7 @@ let x: Vec<u32> = {
     temp_vec.push(3);
     temp_vec
 };
-# assert_eq!(x, [1, 2, 3]);
+# assert_eq!(&[1,2,3], &x);
 ```
 
 We can implement this shorthand, using a macro: [^actual]
@@ -73,7 +73,7 @@ macro_rules! vec {
     };
 }
 # fn main() {
-#     assert_eq!(vec![1,2,3], [1, 2, 3]);
+#     assert_eq!([1,2,3], vec![1,2,3]);
 # }
 ```
 

trunk/src/doc/trpl/macros.md

@@ -477,7 +477,7 @@ forbidden in item signatures to allow reasoning about the types just based in
 the item signature alone. However, for ergonomic reasons a very restricted
 secondary inference algorithm called “lifetime elision” applies in function
 signatures. It infers only based on the signature components themselves and not
-based on the body of the function, only infers lifetime parameters, and does
+based on the body of the function, only infers lifetime paramters, and does
 this with only three easily memorizable and unambiguous rules. This makes
 lifetime elision a shorthand for writing an item signature, while not hiding
 away the actual types involved as full local inference would if applied to it.