---

yaml
---
r: 193342
b: refs/heads/beta
c: c195783
h: refs/heads/master
v: v3

Author: huonw

[refs]

@@ -31,7 +31,7 @@ refs/heads/automation-fail: 1bf06495443584539b958873e04cc2f864ab10e4
 refs/heads/issue-18208-method-dispatch-3-quick-reject: 2009f85b9f99dedcec4404418eda9ddba90258a2
 refs/heads/batch: b7fd822592a4fb577552d93010c4a4e14f314346
 refs/heads/building: 126db549b038c84269a1e4fe46f051b2c15d6970
-refs/heads/beta: 3b30b74692cfee533b45e0380591d237975ec215
+refs/heads/beta: c195783c05d253c8e32fb781cce1ae978f8bd6bd
 refs/heads/windistfix: 7608dbad651f02e837ed05eef3d74a6662a6e928
 refs/tags/1.0.0-alpha: e42bd6d93a1d3433c486200587f8f9e12590a4d7
 refs/heads/tmp: de8a23bbc3a7b9cbd7574b5b91a34af59bf030e6

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

branches/beta/src/doc/reference.md

@@ -2495,6 +2495,12 @@ The currently implemented features of the reference compiler are:
 
 * `staged_api` - Allows usage of stability markers and `#![staged_api]` in a crate
 
+* `static_assert` - The `#[static_assert]` functionality is experimental and
+                    unstable. The attribute can be attached to a `static` of
+                    type `bool` and the compiler will error if the `bool` is
+                    `false` at compile time. This version of this functionality
+                    is unintuitive and suboptimal.
+
 * `start` - Allows use of the `#[start]` attribute, which changes the entry point
             into a Rust program. This capabiilty, especially the signature for the
             annotated function, is subject to change.

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

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