---

yaml
---
r: 216245
b: refs/heads/stable
c: 34601af
h: refs/heads/master
i:
  216243: 2fc02a9
v: v3

Author: luqmana

[refs]

@@ -29,5 +29,5 @@ refs/heads/tmp: 378a370ff2057afeb1eae86eb6e78c476866a4a6
 refs/tags/1.0.0-alpha.2: 4c705f6bc559886632d3871b04f58aab093bfa2f
 refs/tags/homu-tmp: a5286998df566e736b32f6795bfc3803bdaf453d
 refs/tags/1.0.0-beta: 8cbb92b53468ee2b0c2d3eeb8567005953d40828
-refs/heads/stable: 6365080c5cd27b74ec87420c351a3e7bdcff988e
+refs/heads/stable: 34601afd5720eb13aa8cf49a02161802900dacf4
 refs/tags/1.0.0: 55bd4f8ff2b323f317ae89e254ce87162d52a375

branches/stable/src/doc/grammar.md

@@ -96,16 +96,12 @@ explicit codepoint lists. [^inputformat]
 ## Special Unicode Productions
 
 The following productions in the Rust grammar are defined in terms of Unicode
-properties: `ident`, `non_null`, `non_eol`, `non_single_quote` and
-`non_double_quote`.
+properties: `ident`, `non_null`, `non_star`, `non_eol`, `non_slash_or_star`,
+`non_single_quote` and `non_double_quote`.
 
 ### Identifiers
 
-The `ident` production is any nonempty Unicode[^non_ascii_idents] string of
-the following form:
-
-[^non_ascii_idents]: Non-ASCII characters in identifiers are currently feature
-  gated. This is expected to improve soon.
+The `ident` production is any nonempty Unicode string of the following form:
 
 - The first character has property `XID_start`
 - The remaining characters have property `XID_continue`
@@ -122,6 +118,8 @@ Some productions are defined by exclusion of particular Unicode characters:
 
 - `non_null` is any single Unicode character aside from `U+0000` (null)
 - `non_eol` is `non_null` restricted to exclude `U+000A` (`'\n'`)
+- `non_star` is `non_null` restricted to exclude `U+002A` (`*`)
+- `non_slash_or_star` is `non_null` restricted to exclude `U+002F` (`/`) and `U+002A` (`*`)
 - `non_single_quote` is `non_null` restricted to exclude `U+0027`  (`'`)
 - `non_double_quote` is `non_null` restricted to exclude `U+0022` (`"`)
 

branches/stable/src/doc/reference.md

@@ -65,12 +65,15 @@ explicit code point lists. [^inputformat]
   provided to the grammar verifier, restricted to ASCII range, when verifying the
   grammar in this document.
 
-## Identifiers
+## Special Unicode Productions
 
-An identifier is any nonempty Unicode[^non_ascii_idents] string of the following form:
+The following productions in the Rust grammar are defined in terms of Unicode
+properties: `ident`, `non_null`, `non_star`, `non_eol`, `non_slash_or_star`,
+`non_single_quote` and `non_double_quote`.
 
-[^non_ascii_idents]: Non-ASCII characters in identifiers are currently feature
-  gated. This is expected to improve soon.
+### Identifiers
+
+The `ident` production is any nonempty Unicode string of the following form:
 
 - The first character has property `XID_start`
 - The remaining characters have property `XID_continue`
@@ -81,34 +84,42 @@ that does _not_ occur in the set of [keywords](#keywords).
 > character ranges used to form the more familiar C and Java language-family
 > identifiers.
 
+### Delimiter-restricted productions
+
+Some productions are defined by exclusion of particular Unicode characters:
+
+- `non_null` is any single Unicode character aside from `U+0000` (null)
+- `non_eol` is `non_null` restricted to exclude `U+000A` (`'\n'`)
+- `non_star` is `non_null` restricted to exclude `U+002A` (`*`)
+- `non_slash_or_star` is `non_null` restricted to exclude `U+002F` (`/`) and `U+002A` (`*`)
+- `non_single_quote` is `non_null` restricted to exclude `U+0027`  (`'`)
+- `non_double_quote` is `non_null` restricted to exclude `U+0022` (`"`)
+
 ## Comments
 
-Comments in Rust code follow the general C++ style of line (`//`) and
-block-comment (`/* ... */`) forms. Nested block comments are supported.
+Comments in Rust code follow the general C++ style of line and block-comment
+forms. Nested block comments are supported.
 
 Line comments beginning with exactly _three_ slashes (`///`), and block
 comments beginning with exactly one repeated asterisk in the block-open
 sequence (`/**`), are interpreted as a special syntax for `doc`
 [attributes](#attributes). That is, they are equivalent to writing
-`#[doc="..."]` around the body of the comment, i.e., `/// Foo` turns into
-`#[doc="Foo"]`.
+`#[doc="..."]` around the body of the comment (this includes the comment
+characters themselves, i.e. `/// Foo` turns into `#[doc="/// Foo"]`).
 
 Line comments beginning with `//!` and block comments beginning with `/*!` are
 doc comments that apply to the parent of the comment, rather than the item
 that follows.  That is, they are equivalent to writing `#![doc="..."]` around
-the body of the comment. `//!` comments are usually used to document
-modules that occupy a source file.
+the body of the comment. `//!` comments are usually used to display
+information on the crate index page.
 
 Non-doc comments are interpreted as a form of whitespace.
 
 ## Whitespace
 
-Whitespace is any non-empty string containing any the following characters:
-
-- `U+0020` (space, `' '`)
-- `U+0009` (tab, `'\t'`)
-- `U+000A` (LF, `'\n'`)
-- `U+000D` (CR, `'\r'`)
+The `whitespace_char` production is any nonempty Unicode string consisting of
+any of the following Unicode characters: `U+0020` (space, `' '`), `U+0009`
+(tab, `'\t'`), `U+000A` (LF, `'\n'`), `U+000D` (CR, `'\r'`).
 
 Rust is a "free-form" language, meaning that all forms of whitespace serve only
 to separate _tokens_ in the grammar, and have no semantic significance.
@@ -258,11 +269,10 @@ r##"foo #"# bar"##;                // foo #"# bar
 ##### Byte literals
 
 A _byte literal_ is a single ASCII character (in the `U+0000` to `U+007F`
-range) or a single _escape_ preceded by the characters `U+0062` (`b`) and
-`U+0027` (single-quote), and followed by the character `U+0027`. If the character
-`U+0027` is present within the literal, it must be _escaped_ by a preceding
-`U+005C` (`\`) character. It is equivalent to a `u8` unsigned 8-bit integer
-_number literal_.
+range) enclosed within two `U+0027` (single-quote) characters, with the
+exception of `U+0027` itself, which must be _escaped_ by a preceding U+005C
+character (`\`), or a single _escape_. It is equivalent to a `u8` unsigned
+8-bit integer _number literal_.
 
 ##### Byte string literals
 
@@ -1966,7 +1976,7 @@ For any lint check `C`:
 
 The lint checks supported by the compiler can be found via `rustc -W help`,
 along with their default settings.  [Compiler
-plugins](book/compiler-plugins.html#lint-plugins) can provide additional lint checks.
+plugins](book/plugins.html#lint-plugins) can provide additional lint checks.
 
 ```{.ignore}
 mod m1 {
@@ -3636,4 +3646,4 @@ that have since been removed):
   pattern syntax
 
 [ffi]: book/ffi.html
-[plugin]: book/compiler-plugins.html
+[plugin]: book/plugins.html

branches/stable/src/doc/style/testing/unit.md

@@ -1,10 +1,10 @@
 % Unit testing
 
-Unit tests should live in a `tests` submodule at the bottom of the module they
-test. Mark the `tests` submodule with `#[cfg(test)]` so it is only compiled when
+Unit tests should live in a `test` submodule at the bottom of the module they
+test. Mark the `test` submodule with `#[cfg(test)]` so it is only compiled when
 testing.
 
-The `tests` module should contain:
+The `test` module should contain:
 
 * Imports needed only for testing.
 * Functions marked with `#[test]` striving for full coverage of the parent module's
@@ -17,7 +17,7 @@ For example:
 // Excerpt from std::str
 
 #[cfg(test)]
-mod tests {
+mod test {
     #[test]
     fn test_eq() {
         assert!((eq(&"".to_owned(), &"".to_owned())));

branches/stable/src/doc/trpl/README.md

@@ -8,7 +8,7 @@ good at: embedding in other languages, programs with specific space and time
 requirements, and writing low-level code, like device drivers and operating
 systems. It improves on current languages targeting this space by having a
 number of compile-time safety checks that produce no runtime overhead, while
-eliminating all data races. Rust also aims to achieve ‘zero-cost abstractions’
+eliminating all data races. Rust also aims to achieve ‘zero-cost abstrations’
 even though some of these abstractions feel like those of a high-level
 language. Even then, Rust still allows precise control like a low-level
 language would.

branches/stable/src/doc/trpl/closures.md

@@ -294,7 +294,7 @@ is `Fn(i32) -> i32`.
 
 There’s one other key point here: because we’re bounding a generic with a
 trait, this will get monomorphized, and therefore, we’ll be doing static
-dispatch into the closure. That’s pretty neat. In many languages, closures are
+dispatch into the closure. That’s pretty neat. In many langauges, closures are
 inherently heap allocated, and will always involve dynamic dispatch. In Rust,
 we can stack allocate our closure environment, and statically dispatch the
 call. This happens quite often with iterators and their adapters, which often

branches/stable/src/doc/trpl/documentation.md

@@ -556,7 +556,7 @@ This sets a few different options, with a logo, favicon, and a root URL.
 
 ## Generation options
 
-`rustdoc` also contains a few other options on the command line, for further customization:
+`rustdoc` also contains a few other options on the command line, for further customiziation:
 
 - `--html-in-header FILE`: includes the contents of FILE at the end of the
   `<head>...</head>` section.

branches/stable/src/doc/trpl/getting-started.md

@@ -1,5 +1,5 @@
 % Getting Started
 
 This first section of the book will get you going with Rust and its tooling.
-First, we’ll install Rust. Then, the classic ‘Hello World’ program. Finally,
+First, we’ll install Rust. Then: the classic ‘Hello World’ program. Finally,
 we’ll talk about Cargo, Rust’s build system and package manager.

branches/stable/src/doc/trpl/glossary.md

@@ -19,7 +19,7 @@ In the example above `x` and `y` have arity 2. `z` has arity 3.
 
 When a compiler is compiling your program, it does a number of different
 things. One of the things that it does is turn the text of your program into an
-‘abstract syntax tree’, or‘AST’. This tree is a representation of the
+'abstract syntax tree,' or 'AST.' This tree is a representation of the
 structure of your program. For example, `2 + 3` can be turned into a tree:
 
 ```text

branches/stable/src/doc/trpl/mutability.md

@@ -129,7 +129,7 @@ about it first.
 
 ## Field-level mutability
 
-Mutability is a property of either a borrow (`&mut`) or a binding (`let mut`).
+Mutabilty is a property of either a borrow (`&mut`) or a binding (`let mut`).
 This means that, for example, you cannot have a [`struct`][struct] with
 some fields mutable and some immutable:
 

branches/stable/src/doc/trpl/primitive-types.md

@@ -62,14 +62,14 @@ let y = 1.0; // y has type f64
 Here’s a list of the different numeric types, with links to their documentation
 in the standard library:
 
-* [i8](../std/primitive.i8.html)
 * [i16](../std/primitive.i16.html)
 * [i32](../std/primitive.i32.html)
 * [i64](../std/primitive.i64.html)
-* [u8](../std/primitive.u8.html)
+* [i8](../std/primitive.i8.html)
 * [u16](../std/primitive.u16.html)
 * [u32](../std/primitive.u32.html)
 * [u64](../std/primitive.u64.html)
+* [u8](../std/primitive.u8.html)
 * [isize](../std/primitive.isize.html)
 * [usize](../std/primitive.usize.html)
 * [f32](../std/primitive.f32.html)
@@ -82,12 +82,12 @@ Let’s go over them by category:
 Integer types come in two varieties: signed and unsigned. To understand the
 difference, let’s consider a number with four bits of size. A signed, four-bit
 number would let you store numbers from `-8` to `+7`. Signed numbers use
-“two’s compliment representation”. An unsigned four bit number, since it does
+‘two’s compliment representation’. An unsigned four bit number, since it does
 not need to store negatives, can store values from `0` to `+15`.
 
 Unsigned types use a `u` for their category, and signed types use `i`. The `i`
 is for ‘integer’. So `u8` is an eight-bit unsigned number, and `i8` is an
-eight-bit signed number.
+eight-bit signed number. 
 
 ## Fixed size types
 
@@ -103,7 +103,7 @@ and unsigned varieties. This makes for two types: `isize` and `usize`.
 
 ## Floating-point types
 
-Rust also has two floating point types: `f32` and `f64`. These correspond to
+Rust also two floating point types: `f32` and `f64`. These correspond to 
 IEEE-754 single and double precision numbers.
 
 # Arrays
@@ -241,8 +241,8 @@ println!("x is {}", x);
 Remember [before][let] when I said the left-hand side of a `let` statement was more
 powerful than just assigning a binding? Here we are. We can put a pattern on
 the left-hand side of the `let`, and if it matches up to the right-hand side,
-we can assign multiple bindings at once. In this case, `let` “destructures”
-or “breaks up” the tuple, and assigns the bits to three bindings.
+we can assign multiple bindings at once. In this case, `let` "destructures,"
+or "breaks up," the tuple, and assigns the bits to three bindings.
 
 [let]: variable-bindings.html
 

branches/stable/src/doc/trpl/testing.md

@@ -219,10 +219,10 @@ fn it_works() {
 This is a very common use of `assert_eq!`: call some function with
 some known arguments and compare it to the expected output.
 
-# The `tests` module
+# The `test` module
 
 There is one way in which our existing example is not idiomatic: it's
-missing the `tests` module. The idiomatic way of writing our example
+missing the test module. The idiomatic way of writing our example
 looks like this:
 
 ```{rust,ignore}
@@ -231,7 +231,7 @@ pub fn add_two(a: i32) -> i32 {
 }
 
 #[cfg(test)]
-mod tests {
+mod test {
     use super::add_two;
 
     #[test]
@@ -241,7 +241,7 @@ mod tests {
 }
 ```
 
-There's a few changes here. The first is the introduction of a `mod tests` with
+There's a few changes here. The first is the introduction of a `mod test` with
 a `cfg` attribute. The module allows us to group all of our tests together, and
 to also define helper functions if needed, that don't become a part of the rest
 of our crate. The `cfg` attribute only compiles our test code if we're
@@ -260,7 +260,7 @@ pub fn add_two(a: i32) -> i32 {
 }
 
 #[cfg(test)]
-mod tests {
+mod test {
     use super::*;
 
     #[test]
@@ -279,7 +279,7 @@ $ cargo test
      Running target/adder-91b3e234d4ed382a
 
 running 1 test
-test tests::it_works ... ok
+test test::it_works ... ok
 
 test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured
 
@@ -292,7 +292,7 @@ test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured
 
 It works!
 
-The current convention is to use the `tests` module to hold your "unit-style"
+The current convention is to use the `test` module to hold your "unit-style"
 tests. Anything that just tests one small bit of functionality makes sense to
 go here. But what about "integration-style" tests instead? For that, we have
 the `tests` directory
@@ -325,7 +325,7 @@ $ cargo test
      Running target/adder-91b3e234d4ed382a
 
 running 1 test
-test tests::it_works ... ok
+test test::it_works ... ok
 
 test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured
 
@@ -346,7 +346,7 @@ test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured
 Now we have three sections: our previous test is also run, as well as our new
 one.
 
-That's all there is to the `tests` directory. The `tests` module isn't needed
+That's all there is to the `tests` directory. The `test` module isn't needed
 here, since the whole thing is focused on tests.
 
 Let's finally check out that third section: documentation tests.
@@ -382,7 +382,7 @@ pub fn add_two(a: i32) -> i32 {
 }
 
 #[cfg(test)]
-mod tests {
+mod test {
     use super::*;
 
     #[test]
@@ -405,7 +405,7 @@ $ cargo test
      Running target/adder-91b3e234d4ed382a
 
 running 1 test
-test tests::it_works ... ok
+test test::it_works ... ok
 
 test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured
 

branches/stable/src/doc/trpl/trait-objects.md

@@ -155,7 +155,7 @@ A function that takes a trait object is not specialized to each of the types
 that implements `Foo`: only one copy is generated, often (but not always)
 resulting in less code bloat. However, this comes at the cost of requiring
 slower virtual function calls, and effectively inhibiting any chance of
-inlining and related optimizations from occurring.
+inlining and related optimisations from occurring.
 
 ### Why pointers?
 

branches/stable/src/doc/trpl/traits.md

@@ -184,7 +184,7 @@ won’t have its methods:
 ```rust,ignore
 let mut f = std::fs::File::open("foo.txt").ok().expect("Couldn’t open foo.txt");
 let result = f.write("whatever".as_bytes());
-# result.unwrap(); // ignore the error
+# result.unwrap(); // ignore the erorr
 ```
 
 Here’s the error:
@@ -203,7 +203,7 @@ use std::io::Write;
 
 let mut f = std::fs::File::open("foo.txt").ok().expect("Couldn’t open foo.txt");
 let result = f.write("whatever".as_bytes());
-# result.unwrap(); // ignore the error
+# result.unwrap(); // ignore the erorr
 ```
 
 This will compile without error.

branches/stable/src/doc/trpl/variable-bindings.md

@@ -1,6 +1,6 @@
 % Variable Bindings
 
-Virtually every non-'Hello World’ Rust program uses *variable bindings*. They
+Vitually every non-’Hello World’ Rust program uses *variable bindings*. They
 look like this:
 
 ```rust