---

yaml
---
r: 185645
b: refs/heads/master
c: 31ad998
h: refs/heads/master
i:
  185643: 32c3a26
v: v3

Author: dotdash

[refs]

@@ -1,5 +1,5 @@
 ---
-refs/heads/master: 8567f290b840bbdf1149a23faa4ac4c47ab62fb4
+refs/heads/master: 31ad998bfd974a5488665099fe6b5962583fa958
 refs/heads/snap-stage1: e33de59e47c5076a89eadeb38f4934f58a3618a6
 refs/heads/snap-stage3: 3a96d6a9818fe2affc98a187fb1065120458cee9
 refs/heads/try: ccf8fedf1cffcb8f6f3581d53d220039e192fe77

trunk/src/doc/intro.md

@@ -510,10 +510,10 @@ numbers[1] is 3
 numbers[0] is 2
 ```
 
-Each time, we can get a slightly different output because the threads are not
-guaranteed to run in any set order. If you get the same order every time it is
-because each of these threads are very small and complete too fast for their
-indeterminate behavior to surface.
+Each time, we can get a slithtly different output because the threads
+are not quaranteed to run in any set order. If you get the same order
+every time it is because each of these threads are very small and
+complete too fast for their indeterminate behavior to surface.
 
 The important part here is that the Rust compiler was able to use ownership to
 give us assurance _at compile time_ that we weren't doing something incorrect

trunk/src/doc/trpl/guessing-game.md

@@ -422,11 +422,11 @@ In this case, we say `x` is a `u32` explicitly, so Rust is able to properly
 tell `random()` what to generate. In a similar fashion, both of these work:
 
 ```{rust,ignore}
-let input_num_option = "5".parse::<u32>().ok(); // input_num: Option<u32>
-let input_num_result: Result<u32, _> = "5".parse(); // input_num: Result<u32, <u32 as FromStr>::Err>
+let input_num = "5".parse::<u32>(); // input_num: Option<u32>
+let input_num: Result<u32, _> = "5".parse(); // input_num: Result<u32, <u32 as FromStr>::Err>
 ```
 
-Above, we're converting the `Result` returned by `parse` to an `Option` by using
+Here we're converting the `Result` returned by `parse` to an `Option` by using
 the `ok` method as well.  Anyway, with us now converting our input to a number,
 our code looks like this:
 
@@ -470,14 +470,14 @@ Let's try it out!
 ```bash
 $ cargo build
    Compiling guessing_game v0.0.1 (file:///home/you/projects/guessing_game)
-src/main.rs:21:15: 21:24 error: mismatched types: expected `u32`, found `core::result::Result<u32, core::num::ParseIntError>` (expected u32, found enum `core::result::Result`) [E0308]
-src/main.rs:21     match cmp(input_num, secret_number) {
+src/main.rs:22:15: 22:24 error: mismatched types: expected `u32` but found `core::option::Option<u32>` (expected u32 but found enum core::option::Option)
+src/main.rs:22     match cmp(input_num, secret_number) {
                              ^~~~~~~~~
 error: aborting due to previous error
 ```
 
-Oh yeah! Our `input_num` has the type `Result<u32, <some error>>`, rather than `u32`. We
-need to unwrap the Result. If you remember from before, `match` is a great way
+Oh yeah! Our `input_num` has the type `Option<u32>`, rather than `u32`. We
+need to unwrap the Option. If you remember from before, `match` is a great way
 to do that. Try this code:
 
 ```{rust,no_run}
@@ -500,7 +500,7 @@ fn main() {
     let input_num: Result<u32, _> = input.parse();
 
     let num = match input_num {
-        Ok(n) => n,
+        Ok(num) => num,
         Err(_) => {
             println!("Please input a number!");
             return;
@@ -524,7 +524,7 @@ fn cmp(a: u32, b: u32) -> Ordering {
 }
 ```
 
-We use a `match` to either give us the `u32` inside of the `Result`, or else
+We use a `match` to either give us the `u32` inside of the `Option`, or else
 print an error message and return. Let's give this a shot:
 
 ```bash

trunk/src/liballoc/arc.rs

@@ -201,11 +201,10 @@ impl<T> Arc<T> {
 impl<T> Arc<T> {
     #[inline]
     fn inner(&self) -> &ArcInner<T> {
-        // This unsafety is ok because while this arc is alive we're guaranteed
-        // that the inner pointer is valid. Furthermore, we know that the
-        // `ArcInner` structure itself is `Sync` because the inner data is
-        // `Sync` as well, so we're ok loaning out an immutable pointer to these
-        // contents.
+        // This unsafety is ok because while this arc is alive we're guaranteed that the inner
+        // pointer is valid. Furthermore, we know that the `ArcInner` structure itself is `Sync`
+        // because the inner data is `Sync` as well, so we're ok loaning out an immutable pointer
+        // to these contents.
         unsafe { &**self._ptr }
     }
 }
@@ -237,15 +236,13 @@ impl<T> Clone for Arc<T> {
     /// ```
     #[inline]
     fn clone(&self) -> Arc<T> {
-        // Using a relaxed ordering is alright here, as knowledge of the
-        // original reference prevents other threads from erroneously deleting
-        // the object.
+        // Using a relaxed ordering is alright here, as knowledge of the original reference
+        // prevents other threads from erroneously deleting the object.
         //
-        // As explained in the [Boost documentation][1], Increasing the
-        // reference counter can always be done with memory_order_relaxed: New
-        // references to an object can only be formed from an existing
-        // reference, and passing an existing reference from one thread to
-        // another must already provide any required synchronization.
+        // As explained in the [Boost documentation][1], Increasing the reference counter can
+        // always be done with memory_order_relaxed: New references to an object can only be formed
+        // from an existing reference, and passing an existing reference from one thread to another
+        // must already provide any required synchronization.
         //
         // [1]: (www.boost.org/doc/libs/1_55_0/doc/html/atomic/usage_examples.html)
         self.inner().strong.fetch_add(1, Relaxed);

trunk/src/libcollections/fmt.rs

@@ -364,7 +364,7 @@
 //!     * `o` - precedes the argument with a "0o"
 //! * '0' - This is used to indicate for integer formats that the padding should
 //!         both be done with a `0` character as well as be sign-aware. A format
-//!         like `{:08}` would yield `00000001` for the integer `1`, while the
+//!         like `{:08d}` would yield `00000001` for the integer `1`, while the
 //!         same format would yield `-0000001` for the integer `-1`. Notice that
 //!         the negative version has one fewer zero than the positive version.
 //!

trunk/src/libstd/io/lazy.rs

@@ -39,18 +39,13 @@ pub use self::buffered::IntoInnerError;
 pub use self::cursor::Cursor;
 pub use self::error::{Result, Error, ErrorKind};
 pub use self::util::{copy, sink, Sink, empty, Empty, repeat, Repeat};
-pub use self::stdio::{stdin, stdout, stderr, Stdin, Stdout, Stderr};
-pub use self::stdio::{StdoutLock, StderrLock, StdinLock};
-
-#[macro_use] mod lazy;
 
 pub mod prelude;
 mod buffered;
 mod cursor;
 mod error;
 mod impls;
 mod util;
-mod stdio;
 
 const DEFAULT_BUF_SIZE: usize = 64 * 1024;