update original

rustbook-en/dprint.jsonc

@@ -22,12 +22,12 @@
     "second-edition",
     "redirects",
     // has empty list items which look like headings to a formatter
-    ".github/ISSUE_TEMPLATE/bug_report.md"
+    ".github/ISSUE_TEMPLATE/bug_report.md",
   ],
   "plugins": [
     "https://plugins.dprint.dev/typescript-0.93.3.wasm",
     "https://plugins.dprint.dev/json-0.19.4.wasm",
     "https://plugins.dprint.dev/markdown-0.17.8.wasm",
-    "https://plugins.dprint.dev/g-plane/malva-v0.11.0.wasm"
-  ]
+    "https://plugins.dprint.dev/g-plane/malva-v0.11.0.wasm",
+  ],
 }

rustbook-en/nostarch/book.toml

@@ -1,6 +1,6 @@
 [book]
 title = "The Rust Programming Language"
-authors = ["Steve Klabnik", "Carol Nichols", "Contributions from the Rust Community"]
+authors = ["Steve Klabnik", "Carol Nichols", "Chris Krycho", "Contributions from the Rust Community"]
 src = "../src" # needs to be explicit (it is implicit in `/book.toml`).
 
 [output.html]

rustbook-en/src/ch17-01-futures-and-syntax.md

@@ -44,8 +44,8 @@ everything you need to know as we go.
 To keep this chapter focused on learning async, rather than juggling parts of
 the ecosystem, we have created the `trpl` crate (`trpl` is short for “The Rust
 Programming Language”). It re-exports all the types, traits, and functions
-you’ll need, primarily from the [`futures`][futures-crate] and [`tokio`][tokio]
-crates.
+you’ll need, primarily from the [`futures`][futures-crate]<!-- ignore --> and
+[`tokio`][tokio]<!-- ignore --> crates.
 
 - The `futures` crate is an official home for Rust experimentation for async
   code, and is actually where the `Future` type was originally designed.
@@ -57,9 +57,10 @@ crates.
 
 In some cases, `trpl` also renames or wraps the original APIs to let us stay
 focused on the details relevant to this chapter. If you want to understand what
-the crate does, we encourage you to check out [its source code][crate-source].
-You’ll be able to see what crate each re-export comes from, and we’ve left
-extensive comments explaining what the crate does.
+the crate does, we encourage you to check out [its source
+code][crate-source]<!-- ignore -->. You’ll be able to see what crate each
+re-export comes from, and we’ve left extensive comments explaining what the
+crate does.
 
 Create a new binary project named `hello-async` and add the `trpl` crate as a
 dependency:
@@ -101,7 +102,8 @@ also async.
 We have to explicitly await both of these futures, because futures in Rust are
 _lazy_: they don’t do anything until you ask them to with `await`. (In fact,
 Rust will show a compiler warning if you don’t use a future.) This should
-remind you of our discussion of iterators [back in Chapter 13][iterators-lazy].
+remind you of our discussion of iterators [back in Chapter 13][iterators-lazy]<!--
+ignore -->.
 Iterators do nothing unless you call their `next` method—whether directly, or
 using `for` loops or methods such as `map` which use `next` under the hood. With
 futures, the same basic idea applies: they do nothing unless you explicitly ask
@@ -174,7 +176,7 @@ fn page_title(url: &str) -> impl Future<Output = Option<String>> + '_ {
 Let’s walk through each part of the transformed version:
 
 - It uses the `impl Trait` syntax we discussed back in the [“Traits as
-  Parameters”][impl-trait] section in Chapter 10.
+  Parameters”][impl-trait]<!-- ignore --> section in Chapter 10.
 - The returned trait is a `Future`, with an associated type of `Output`. Notice
   that the `Output` type is `Option<String>`, which is the same as the the
   original return type from the `async fn` version of `page_title`.

rustbook-en/src/ch17-02-concurrency-with-async.md

@@ -380,5 +380,3 @@ received 'you'
 
 This is a good start, but it limits us to just a handful of futures: two with
 `join`, or three with `join3`. Let’s see how we might work with more futures.
-
-[streams]: ch17-05-streams.html

rustbook-en/src/ch17-03-more-futures.md

@@ -71,7 +71,7 @@ structs in a `Vec`, and the same thing applies to the different structs
 generated by the compiler.
 
 To make this work, we need to use _trait objects_, just as we did in [“Returning
-Errors from the run function”][dyn] in Chapter 12. (We’ll cover trait objects
+Errors from the run function”][dyn]<!-- ignore --> in Chapter 12. (We’ll cover trait objects
 in detail in Chapter 18.) Using trait objects lets us treat each of the
 anonymous futures produced by these types as the same type, because all of them
 implement the `Future` trait.
@@ -330,9 +330,9 @@ In Listing 17-21, we once again use `trpl::race` to run two futures, `slow` and
 pauses for some amount of time by calling and awaiting `sleep`, and then prints
 another message when it finishes. Then we pass both to `trpl::race` and wait for
 one of them to finish. (The outcome here won’t be too surprising: `fast` wins!)
-Unlike when we used `race` back in [Our First Async Program][async-program], we
-just ignore the `Either` instance it returns here, because all of the
-interesting behavior happens in the body of the async blocks.
+Unlike when we used `race` back in [“Our First Async Program”][async-program]<!--
+ignore -->, we just ignore the `Either` instance it returns here, because all of
+the interesting behavior happens in the body of the async blocks.
 
 <Listing number="17-21" caption="Using `race` to get the result of whichever future finishes first" file-name="src/main.rs">
 
@@ -351,7 +351,7 @@ to poll first. Regardless of whether the implementation of race we’re using is
 fair, though, _one_ of the futures will run up to the first `await` in its body
 before another task can start.
 
-Recall from [Our First Async Program][async-program] that at each await point,
+Recall from [Our First Async Program][async-program]<!-- ignore --> that at each await point,
 Rust gives a runtime a chance to pause the task and switch to another one if the
 future being awaited isn’t ready. The inverse is also true: Rust _only_ pauses
 async blocks and hands control back to a runtime at an await point. Everything

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

@@ -2,7 +2,7 @@
 
 So far in this chapter, we have mostly stuck to individual futures. The one big
 exception was the async channel we used. Recall how we used the receiver for our
-async channel in the [“Message Passing”][17-02-messages] earlier in the chapter.
+async channel in the [“Message Passing”][17-02-messages]<!-- ignore --> earlier in the chapter.
 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_.
 

rustbook-en/src/ch17-05-traits-for-async.md

@@ -10,9 +10,9 @@ still leaving the _really_ deep dive for other documentation!
 
 ### Future
 
-Back in [Futures and the Async Syntax][futures-syntax], we noted that `Future`
-is a trait. Let’s start by taking a closer look at how it works. Here is how
-Rust defines a `Future`:
+Back in [“Futures and the Async Syntax”][futures-syntax]<!-- ignore -->, we
+noted that `Future` is a trait. Let’s start by taking a closer look at how it
+works. Here is how Rust defines a `Future`:
 
 ```rust
 use std::pin::Pin;

rustbook-en/src/ch21-01-single-threaded.md

@@ -141,7 +141,7 @@ connection, we now call the new `handle_connection` function and pass the
 `stream` to it.
 
 In the `handle_connection` function, we create a new `BufReader` instance that
-wraps a reference to the `stream`. `BufReader` adds buffering by managing calls
+wraps a reference to the `stream`. The `BufReader` adds buffering by managing calls
 to the `std::io::Read` trait methods for us.
 
 We create a variable named `http_request` to collect the lines of the request