update original

rustbook-en/listings/ch04-understanding-ownership/listing-04-03/src/main.rs

@@ -6,9 +6,9 @@ fn main() {
 
     let x = 5;                      // x comes into scope
 
-    makes_copy(x);                  // x would move into the function,
-                                    // but i32 is Copy, so it's okay to still
-                                    // use x afterward
+    makes_copy(x);                  // because i32 implements the Copy trait,
+                                    // x does NOT move into the function,
+    println!("{}", x);              // so it's okay to use x afterward
 
 } // Here, x goes out of scope, then s. But because s's value was moved, nothing
   // special happens.

rustbook-en/src/ch08-02-strings.md

@@ -278,8 +278,8 @@ seem that `answer` should in fact be `208`, but `208` is not a valid character
 on its own. Returning `208` is likely not what a user would want if they asked
 for the first letter of this string; however, that’s the only data that Rust
 has at byte index 0. Users generally don’t want the byte value returned, even
-if the string contains only Latin letters: if `&"hello"[0]` were valid code
-that returned the byte value, it would return `104`, not `h`.
+if the string contains only Latin letters: if `&"hi"[0]` were valid code that
+returned the byte value, it would return `104`, not `h`.
 
 The answer, then, is that to avoid returning an unexpected value and causing
 bugs that might not be discovered immediately, Rust doesn’t compile this code

rustbook-en/src/ch11-02-running-tests.md

@@ -13,7 +13,12 @@ binary. To separate these two types of arguments, you list the arguments that
 go to `cargo test` followed by the separator `--` and then the ones that go to
 the test binary. Running `cargo test --help` displays the options you can use
 with `cargo test`, and running `cargo test -- --help` displays the options you
-can use after the separator.
+can use after the separator. Those options are also documented in [the “Tests”
+section][tests] of the [the rustc book][rustc].
+
+[tests]: https://doc.rust-lang.org/rustc/tests/index.html
+[rustc]: https://doc.rust-lang.org/rustc/index.html
+
 
 ### Running Tests in Parallel or Consecutively
 

rustbook-en/src/ch17-04-streams.md

@@ -7,13 +7,12 @@ The async `recv` method produces a sequence of items over time. This is an
 instance of a much more general pattern, often called a *stream*.
 
 A sequence of items is something we’ve seen before, when we looked at the
-`Iterator` trait in Chapter 13, but there are two differences between iterators
-and the async channel receiver. The first difference is the element of time:
-iterators are synchronous, while the channel receiver is asynchronous. The
-second difference is the API. When working directly with an `Iterator`, we call
-its synchronous `next` method. With the `trpl::Receiver` stream in particular,
-we called an  asynchronous `recv` method instead, but these APIs otherwise feel
-very similar.
+`Iterator` trait in Chapter 13. There are two differences between iterators and
+the async channel receiver, though. The first is the element of time: iterators
+are synchronous, while the channel receiver is asynchronous. The second is the
+API. When working directly with an `Iterator`, we call its synchronous `next`
+method. With the `trpl::Receiver` stream in particular, we called an
+asynchronous `recv` method instead. These APIs otherwise feel very similar.
 
 That similarity isn’t a coincidence. A stream is similar to an asynchronous
 form of iteration. Whereas the `trpl::Receiver` specifically waits to receive