---

yaml
---
r: 196269
b: refs/heads/tmp
c: a547962
h: refs/heads/master
i:
  196267: c6487cb
v: v3

Author: nrc

[refs]

@@ -32,7 +32,7 @@ refs/heads/building: 126db549b038c84269a1e4fe46f051b2c15d6970
 refs/heads/beta: 9854143cba679834bc4ef932858cd5303f015a0e
 refs/heads/windistfix: 7608dbad651f02e837ed05eef3d74a6662a6e928
 refs/tags/1.0.0-alpha: e42bd6d93a1d3433c486200587f8f9e12590a4d7
-refs/heads/tmp: debac97a10ce7fec71ab16101889f7ec5ea17e71
+refs/heads/tmp: a5479622eac34ee38e07763a02ac1f9ec118a66b
 refs/tags/1.0.0-alpha.2: 4c705f6bc559886632d3871b04f58aab093bfa2f
 refs/tags/homu-tmp: 53a183f0274316596bf9405944d4f0468d8c93e4
 refs/heads/gate: 97c84447b65164731087ea82685580cc81424412

branches/tmp/src/compiletest/compiletest.rs

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

branches/tmp/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]);

branches/tmp/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)

branches/tmp/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
 

branches/tmp/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);
 }
 ```

branches/tmp/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]);
 # }
 ```
 

branches/tmp/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.