nostarch: update Word documents with revisions from web version

listings/ch08-common-collections/listing-08-19/src/main.rs

@@ -1,6 +1,6 @@
 fn main() {
     // ANCHOR: here
-    let s1 = String::from("hello");
+    let s1 = String::from("hi");
     let h = s1[0];
     // ANCHOR_END: here
 }

src/ch03-05-control-flow.md

@@ -283,7 +283,7 @@ that Rust has a built-in language construct for it, called a `while` loop. In
 Listing 3-3, we use `while` to loop the program three times, counting down each
 time, and then, after the loop, print a message and exit.
 
-<Listing number="3-3" file-name="src/main.rs" caption="Using a `while` loop to run code while a condition holds true">
+<Listing number="3-3" file-name="src/main.rs" caption="Using a `while` loop to run code while a condition evaluates to `true`">
 
 ```rust
 {{#rustdoc_include ../listings/ch03-common-programming-concepts/listing-03-03/src/main.rs}}

src/ch05-01-defining-structs.md

@@ -23,8 +23,8 @@ struct that stores information about a user account.
 
 To use a struct after we’ve defined it, we create an _instance_ of that struct
 by specifying concrete values for each of the fields. We create an instance by
-stating the name of the struct and then add curly brackets containing _key:
-value_ pairs, where the keys are the names of the fields and the values are the
+stating the name of the struct and then add curly brackets containing _`key:
+value`_ pairs, where the keys are the names of the fields and the values are the
 data we want to store in those fields. We don’t have to specify the fields in
 the same order in which we declared them in the struct. In other words, the
 struct definition is like a general template for the type, and instances fill
@@ -148,7 +148,7 @@ Move”][move]<!-- ignore --> section. In this example, we can no longer use
 valid after creating `user2`. Both `active` and `sign_in_count` are types that
 implement the `Copy` trait, so the behavior we discussed in the [“Stack-Only
 Data: Copy”][copy]<!-- ignore --> section would apply. We can still use
-`user1.email` in this example, since its value was _not_ moved out.
+`user1.email` in this example, because its value was not moved out of `user1`.
 
 ### Using Tuple Structs Without Named Fields to Create Different Types
 

src/ch05-02-example-structs.md

@@ -78,7 +78,7 @@ parts, as shown in Listing 5-10.
 
 </Listing>
 
-Here we’ve defined a struct and named it `Rectangle`. Inside the curly
+Here, we’ve defined a struct and named it `Rectangle`. Inside the curly
 brackets, we defined the fields as `width` and `height`, both of which have
 type `u32`. Then, in `main`, we created a particular instance of `Rectangle`
 that has a width of `30` and a height of `50`.

src/ch05-03-method-syntax.md

@@ -5,7 +5,7 @@ name, they can have parameters and a return value, and they contain some code
 that’s run when the method is called from somewhere else. Unlike functions,
 methods are defined within the context of a struct (or an enum or a trait
 object, which we cover in [Chapter 6][enums]<!-- ignore --> and [Chapter
-17][trait-objects]<!-- ignore -->, respectively), and their first parameter is
+18][trait-objects]<!-- ignore -->, respectively), and their first parameter is
 always `self`, which represents the instance of the struct the method is being
 called on.
 

src/ch06-03-if-let.md

@@ -62,7 +62,7 @@ Or we could use an `if let` and `else` expression, like this:
 {{#rustdoc_include ../listings/ch06-enums-and-pattern-matching/no-listing-14-count-and-announce-if-let-else/src/main.rs:here}}
 ```
 
-## Staying on the “happy path” with `let else`
+## Staying on the “Happy Path” with `let else`
 
 One common pattern is to perform some computation when a value is present and
 return a default value otherwise. Continuing on with our example of coins with a
@@ -77,7 +77,7 @@ age of a state, like so:
 Then we might use `if let` to match on the type of coin, introducing a `state`
 variable within the body of the condition, as in Listing 6-7.
 
-<Listing number="6-7" caption="Using" file-name="src/main.rs">
+<Listing number="6-7" caption="Checking whether a state existing in 1900 by using conditionals nested inside an `if let`." file-name="src/main.rs">
 
 ```rust
 {{#rustdoc_include ../listings/ch06-enums-and-pattern-matching/listing-06-07/src/main.rs:describe}}
@@ -90,7 +90,7 @@ statement, and if the work to be done is more complicated, it might be hard to
 follow exactly how the top-level branches relate. We could also take advantage
 of the fact that expressions produce a value either to produce the `state` from
 the `if let` or to return early, as in Listing 6-8. (You could do similar with a
-`match`, of course!)
+`match`, too.)
 
 <Listing number="6-8" caption="Using `if let` to produce a value or return early." file-name="src/main.rs">
 

src/ch07-01-packages-and-crates.md

@@ -32,9 +32,11 @@ build those crates. Cargo is actually a package that contains the binary crate
 for the command line tool you’ve been using to build your code. The Cargo
 package also contains a library crate that the binary crate depends on. Other
 projects can depend on the Cargo library crate to use the same logic the Cargo
-command line tool uses. A package can contain as many binary crates as you
-like, but at most only one library crate. A package must contain at least one
-crate, whether that’s a library or binary crate.
+command line tool uses.
+
+A package can contain as many binary crates as you like, but at most only one
+library crate. A package must contain at least one crate, whether that’s a
+library or binary crate.
 
 Let’s walk through what happens when we create a package. First we enter the
 command `cargo new my-project`:

src/ch10-03-lifetime-syntax.md

@@ -429,11 +429,11 @@ _lifetime elision rules_. These aren’t rules for programmers to follow; they
 a set of particular cases that the compiler will consider, and if your code
 fits these cases, you don’t need to write the lifetimes explicitly.
 
-The elision rules don’t provide full inference. If there is still ambiguity as
-to what lifetimes the references have after Rust applies the rules, the
+The elision rules don’t provide full inference. If there is still ambiguity
+about what lifetimes the references have after Rust applies the rules, the
 compiler won’t guess what the lifetime of the remaining references should be.
-Instead of guessing, the compiler will give you an error that you can resolve
-by adding the lifetime annotations.
+Instead of guessing, the compiler will give you an error that you can resolve by
+adding the lifetime annotations.
 
 Lifetimes on function or method parameters are called _input lifetimes_, and
 lifetimes on return values are called _output lifetimes_.

src/ch11-01-writing-tests.md

@@ -327,7 +327,7 @@ assertion functions are called `expected` and `actual`, and the order in which
 we specify the arguments matters. However, in Rust, they’re called `left` and
 `right`, and the order in which we specify the value we expect and the value the
 code produces doesn’t matter. We could write the assertion in this test as
-`assert_eq!(4, result)`, which would result in the same failure message that
+`assert_eq!(add_two(2), result)`, which would result in the same failure message
 that displays `` assertion failed: `(left == right)` ``.
 
 The `assert_ne!` macro will pass if the two values we give it are not equal and