Update for markdown changes. (#1984)

Update for markdown changes.

ci/dictionary.txt

@@ -519,6 +519,7 @@ variable's
 variant's
 vers
 versa
+vert
 Versioning
 visualstudio
 Vlissides

src/appendix-02-operators.md

@@ -36,7 +36,7 @@ overload that operator is listed.
 | `-` | `- expr` | Arithmetic negation | `Neg` |
 | `-` | `expr - expr` | Arithmetic subtraction | `Sub` |
 | `-=` | `var -= expr` | Arithmetic subtraction and assignment | `SubAssign` |
-| `->` | `fn(...) -> type`, <code>\|...\| -> type</code> | Function and closure return type | |
+| `->` | `fn(...) -> type`, <code>&vert;...&vert; -> type</code> | Function and closure return type | |
 | `.` | `expr.ident` | Member access | |
 | `..` | `..`, `expr..`, `..expr`, `expr..expr` | Right-exclusive range literal | |
 | `..=` | `..=expr`, `expr..=expr` | Right-inclusive range literal | |
@@ -64,10 +64,10 @@ overload that operator is listed.
 | `@` | `ident @ pat` | Pattern binding | |
 | `^` | `expr ^ expr` | Bitwise exclusive OR | `BitXor` |
 | `^=` | `var ^= expr` | Bitwise exclusive OR and assignment | `BitXorAssign` |
-| <code>\|</code> | <code>pat \| pat</code> | Pattern alternatives | |
-| <code>\|</code> | <code>expr \| expr</code> | Bitwise OR | `BitOr` |
-| <code>\|=</code> | <code>var \|= expr</code> | Bitwise OR and assignment | `BitOrAssign` |
-| <code>\|\|</code> | <code>expr \|\| expr</code> | Logical OR | |
+| <code>&vert;</code> | <code>pat &vert; pat</code> | Pattern alternatives | |
+| <code>&vert;</code> | <code>expr &vert; expr</code> | Bitwise OR | `BitOr` |
+| <code>&vert;=</code> | <code>var &vert;= expr</code> | Bitwise OR and assignment | `BitOrAssign` |
+| <code>&vert;&vert;</code> | <code>expr &vert;&vert; expr</code> | Logical OR | |
 | `?` | `expr?` | Error propagation | |
 
 ### Non-operator Symbols
@@ -90,7 +90,7 @@ locations.
 | `br"..."`, `br#"..."#`, `br##"..."##`, etc. | Raw byte string literal, combination of raw and byte string literal |
 | `'...'` | Character literal |
 | `b'...'` | ASCII byte literal |
-| <code>\|...\| expr</code> | Closure |
+| <code>&vert;...&vert; expr</code> | Closure |
 | `!` | Always empty bottom type for diverging functions |
 | `_` | “Ignored” pattern binding; also used to make integer literals readable |
 

src/appendix-03-derivable-traits.md

@@ -125,9 +125,9 @@ returned from `to_vec` will need to own its instances, so `to_vec` calls
 `clone` on each item. Thus, the type stored in the slice must implement `Clone`.
 
 The `Copy` trait allows you to duplicate a value by only copying bits stored on
-the stack; no arbitrary code is necessary. See the [“Stack-Only Data: Copy”]
-[stack-only-data-copy]<!-- ignore --> section in Chapter 4 for more information
-on `Copy`.
+the stack; no arbitrary code is necessary. See the [“Stack-Only Data:
+Copy”][stack-only-data-copy]<!-- ignore --> section in Chapter 4 for more
+information on `Copy`.
 
 The `Copy` trait doesn’t define any methods to prevent programmers from
 overloading those methods and violating the assumption that no arbitrary code
@@ -167,9 +167,9 @@ derive `Default`.
 
 The `Default::default` function is commonly used in combination with the struct
 update syntax discussed in the [“Creating Instances From Other Instances With
-Struct Update Syntax”]
-[creating-instances-from-other-instances-with-struct-update-syntax]<!-- ignore
---> section in Chapter 5. You can customize a few fields of a struct and then
+Struct Update
+Syntax”][creating-instances-from-other-instances-with-struct-update-syntax]<!-- ignore -->
+section in Chapter 5. You can customize a few fields of a struct and then
 set and use a default value for the rest of the fields by using
 `..Default::default()`.
 

src/appendix-05-editions.md

@@ -1,4 +1,5 @@
 # Appendix E - Editions
+
 In Chapter 1, you saw that `cargo new` adds a bit of metadata to your
 *Cargo.toml* file about an edition. This appendix talks about what that means!
 

src/ch01-03-hello-cargo.md

@@ -13,10 +13,10 @@ using Cargo, adding dependencies will be much easier to do.
 
 Because the vast majority of Rust projects use Cargo, the rest of this book
 assumes that you’re using Cargo too. Cargo comes installed with Rust if you
-used the official installers discussed in the [“Installation”]
-[installation]<!-- ignore --> section. If you installed Rust through some other
-means, check whether Cargo is installed by entering the following into your
-terminal:
+used the official installers discussed in the
+[“Installation”][installation]<!-- ignore --> section. If you installed Rust
+through some other means, check whether Cargo is installed by entering the
+following into your terminal:
 
 ```text
 $ cargo --version

src/ch02-00-guessing-game-tutorial.md

@@ -157,10 +157,10 @@ let foo = bar;
 
 This line creates a new variable named `foo` and binds it to the value of the
 `bar` variable. In Rust, variables are immutable by default. We’ll be
-discussing this concept in detail in the [“Variables and Mutability”]
-[variables-and-mutability]<!-- ignore --> section in Chapter 3. The following
-example shows how to use `mut` before the variable name to make a variable
-mutable:
+discussing this concept in detail in the [“Variables and
+Mutability”][variables-and-mutability]<!-- ignore --> section in Chapter 3.
+The following example shows how to use `mut` before the variable name to make
+a variable mutable:
 
 ```rust,ignore
 let foo = 5; // immutable

src/ch03-02-data-types.md

@@ -8,9 +8,9 @@ Keep in mind that Rust is a *statically typed* language, which means that it
 must know the types of all variables at compile time. The compiler can usually
 infer what type we want to use based on the value and how we use it. In cases
 when many types are possible, such as when we converted a `String` to a numeric
-type using `parse` in the [“Comparing the Guess to the Secret Number”]
-[comparing-the-guess-to-the-secret-number]<!-- ignore --> section in Chapter 2,
-we must add a type annotation, like this:
+type using `parse` in the [“Comparing the Guess to the Secret
+Number”][comparing-the-guess-to-the-secret-number]<!-- ignore --> section in
+Chapter 2, we must add a type annotation, like this:
 
 ```rust
 let guess: u32 = "42".parse().expect("Not a number!");
@@ -107,7 +107,8 @@ which you’d use `isize` or `usize` is when indexing some sort of collection.
 > checks for integer overflow that cause your program to *panic* at runtime if
 > this behavior occurs. Rust uses the term panicking when a program exits with
 > an error; we’ll discuss panics in more depth in the [“Unrecoverable Errors
-> with `panic!`”][unrecoverable-errors-with-panic] section in Chapter 9.
+> with `panic!`”][unrecoverable-errors-with-panic]<!-- ignore --> section in
+> Chapter 9.
 >
 > When you’re compiling in release mode with the `--release` flag, Rust does
 > *not* include checks for integer overflow that cause panics. Instead, if

src/ch03-05-control-flow.md

@@ -35,8 +35,9 @@ condition. In this case, the condition checks whether or not the variable
 condition is true is placed immediately after the condition inside curly
 brackets. Blocks of code associated with the conditions in `if` expressions are
 sometimes called *arms*, just like the arms in `match` expressions that we
-discussed in the [“Comparing the Guess to the Secret Number”]
-[comparing-the-guess-to-the-secret-number]<!-- ignore --> section of Chapter 2.
+discussed in the [“Comparing the Guess to the Secret
+Number”][comparing-the-guess-to-the-secret-number]<!-- ignore --> section of
+Chapter 2.
 
 Optionally, we can also include an `else` expression, which we chose
 to do here, to give the program an alternative block of code to execute should

src/ch08-03-hash-maps.md

@@ -100,8 +100,9 @@ they’ve been moved into the hash map with the call to `insert`.
 If we insert references to values into the hash map, the values won’t be moved
 into the hash map. The values that the references point to must be valid for at
 least as long as the hash map is valid. We’ll talk more about these issues in
-the [“Validating References with Lifetimes”]
-[validating-references-with-lifetimes]<!-- ignore --> section in Chapter 10.
+the [“Validating References with
+Lifetimes”][validating-references-with-lifetimes]<!-- ignore --> section in
+Chapter 10.
 
 ### Accessing Values in a Hash Map
 

src/ch09-01-unrecoverable-errors-with-panic.md

@@ -192,9 +192,9 @@ you’ll need to figure out what action the code is taking with what values to
 cause the panic and what the code should do instead.
 
 We’ll come back to `panic!` and when we should and should not use `panic!` to
-handle error conditions in the [“To `panic!` or Not to `panic!`”]
-[to-panic-or-not-to-panic]<!-- ignore --> section later in this chapter. Next,
-we’ll look at how to recover from an error using `Result`.
+handle error conditions in the [“To `panic!` or Not to
+`panic!`”][to-panic-or-not-to-panic]<!-- ignore --> section later in this
+chapter. Next, we’ll look at how to recover from an error using `Result`.
 
 [to-panic-or-not-to-panic]:
 ch09-03-to-panic-or-not-to-panic.html#to-panic-or-not-to-panic

src/ch10-02-traits.md

@@ -480,13 +480,14 @@ error[E0507]: cannot move out of borrowed content
 
 The key line in this error is `cannot move out of type [T], a non-copy slice`.
 With our non-generic versions of the `largest` function, we were only trying to
-find the largest `i32` or `char`. As discussed in the [“Stack-Only Data: Copy”]
-[stack-only-data-copy]<!-- ignore --> section in Chapter 4, types like `i32`
-and `char` that have a known size can be stored on the stack, so they implement
-the `Copy` trait. But when we made the `largest` function generic, it became
-possible for the `list` parameter to have types in it that don’t implement the
-`Copy` trait. Consequently, we wouldn’t be able to move the value out of
-`list[0]` and into the `largest` variable, resulting in this error.
+find the largest `i32` or `char`. As discussed in the [“Stack-Only Data:
+Copy”][stack-only-data-copy]<!-- ignore --> section in Chapter 4, types like
+`i32` and `char` that have a known size can be stored on the stack, so they
+implement the `Copy` trait. But when we made the `largest` function generic,
+it became possible for the `list` parameter to have types in it that don’t
+implement the `Copy` trait. Consequently, we wouldn’t be able to move the
+value out of `list[0]` and into the `largest` variable, resulting in this
+error.
 
 To call this code with only those types that implement the `Copy` trait, we can
 add `Copy` to the trait bounds of `T`! Listing 10-15 shows the complete code of

src/ch10-03-lifetime-syntax.md

@@ -1,14 +1,15 @@
 ## Validating References with Lifetimes
 
-One detail we didn’t discuss in the [“References and Borrowing”]
-[references-and-borrowing]<!-- ignore --> section in Chapter 4 is that every
-reference in Rust has a *lifetime*, which is the scope for which that reference
-is valid. Most of the time, lifetimes are implicit and inferred, just like most
-of the time, types are inferred. We must annotate types when multiple types are
-possible. In a similar way, we must annotate lifetimes when the lifetimes of
-references could be related in a few different ways. Rust requires us to
-annotate the relationships using generic lifetime parameters to ensure the
-actual references used at runtime will definitely be valid.
+One detail we didn’t discuss in the [“References and
+Borrowing”][references-and-borrowing]<!-- ignore --> section in Chapter 4 is
+that every reference in Rust has a *lifetime*, which is the scope for which
+that reference is valid. Most of the time, lifetimes are implicit and
+inferred, just like most of the time, types are inferred. We must annotate
+types when multiple types are possible. In a similar way, we must annotate
+lifetimes when the lifetimes of references could be related in a few different
+ways. Rust requires us to annotate the relationships using generic lifetime
+parameters to ensure the actual references used at runtime will definitely be
+valid.
 
 The concept of lifetimes is somewhat different from tools in other programming
 languages, arguably making lifetimes Rust’s most distinctive feature. Although

src/ch11-01-writing-tests.md

@@ -105,8 +105,8 @@ reads `1 passed; 0 failed` totals the number of tests that passed or failed.
 Because we don’t have any tests we’ve marked as ignored, the summary shows `0
 ignored`. We also haven’t filtered the tests being run, so the end of the
 summary shows `0 filtered out`. We’ll talk about ignoring and filtering out
-tests in the next section, [“Controlling How Tests Are Run.”]
-[controlling-how-tests-are-run]<!-- ignore -->
+tests in the next section, [“Controlling How Tests Are
+Run.”][controlling-how-tests-are-run]<!-- ignore -->
 
 The `0 measured` statistic is for benchmark tests that measure performance.
 Benchmark tests are, as of this writing, only available in nightly Rust. See
@@ -509,12 +509,12 @@ optional arguments to the `assert!`, `assert_eq!`, and `assert_ne!` macros. Any
 arguments specified after the one required argument to `assert!` or the two
 required arguments to `assert_eq!` and `assert_ne!` are passed along to the
 `format!` macro (discussed in Chapter 8 in the [“Concatenation with the `+`
-Operator or the `format!` Macro”]
-[concatenation-with-the--operator-or-the-format-macro]<!-- ignore --> section),
-so you can pass a format string that contains `{}` placeholders and values to
-go in those placeholders. Custom messages are useful to document what an
-assertion means; when a test fails, you’ll have a better idea of what the
-problem is with the code.
+Operator or the `format!`
+Macro”][concatenation-with-the--operator-or-the-format-macro]<!-- ignore -->
+section), so you can pass a format string that contains `{}` placeholders and
+values to go in those placeholders. Custom messages are useful to document
+what an assertion means; when a test fails, you’ll have a better idea of what
+the problem is with the code.
 
 For example, let’s say we have a function that greets people by name and we
 want to test that the name we pass into the function appears in the output:

src/ch12-03-improving-error-handling-and-modularity.md

@@ -187,14 +187,15 @@ trade-off.
 > ### The Trade-Offs of Using `clone`
 >
 > There’s a tendency among many Rustaceans to avoid using `clone` to fix
-> ownership problems because of its runtime cost. In [Chapter 13][ch13]<!--
-> ignore -->, you’ll learn how to use more efficient methods in this type of
-> situation. But for now, it’s okay to copy a few strings to continue making
-> progress because you’ll make these copies only once and your filename and
-> query string are very small. It’s better to have a working program that’s a
-> bit inefficient than to try to hyperoptimize code on your first pass. As you
-> become more experienced with Rust, it’ll be easier to start with the most
-> efficient solution, but for now, it’s perfectly acceptable to call `clone`.
+> ownership problems because of its runtime cost. In
+> [Chapter 13][ch13]<!-- ignore -->, you’ll learn how to use more efficient
+> methods in this type of situation. But for now, it’s okay to copy a few
+> strings to continue making progress because you’ll make these copies only
+> once and your filename and query string are very small. It’s better to have
+> a working program that’s a bit inefficient than to try to hyperoptimize code
+> on your first pass. As you become more experienced with Rust, it’ll be
+> easier to start with the most efficient solution, but for now, it’s
+> perfectly acceptable to call `clone`.
 
 We’ve updated `main` so it places the instance of `Config` returned by
 `parse_config` into a variable named `config`, and we updated the code that

src/ch16-04-extensible-concurrency-sync-and-send.md

@@ -42,8 +42,8 @@ The smart pointer `Rc<T>` is also not `Sync` for the same reasons that it’s no
 family of related `Cell<T>` types are not `Sync`. The implementation of borrow
 checking that `RefCell<T>` does at runtime is not thread-safe. The smart
 pointer `Mutex<T>` is `Sync` and can be used to share access with multiple
-threads as you saw in the [“Sharing a `Mutex<T>` Between Multiple Threads”]
-[sharing-a-mutext-between-multiple-threads]<!-- ignore --> section.
+threads as you saw in the [“Sharing a `Mutex<T>` Between Multiple
+Threads”][sharing-a-mutext-between-multiple-threads]<!-- ignore --> section.
 
 ### Implementing `Send` and `Sync` Manually Is Unsafe
 

src/ch17-02-trait-objects.md

@@ -331,17 +331,17 @@ didn’t mean to pass and we should pass a different type or we should implement
 
 ### Trait Objects Perform Dynamic Dispatch
 
-Recall in the [“Performance of Code Using Generics”]
-[performance-of-code-using-generics]<!-- ignore --> section in Chapter 10 our
-discussion on the monomorphization process performed by the compiler when we
-use trait bounds on generics: the compiler generates nongeneric implementations
-of functions and methods for each concrete type that we use in place of a
-generic type parameter. The code that results from monomorphization is doing
-*static dispatch*, which is when the compiler knows what method you’re calling
-at compile time. This is opposed to *dynamic dispatch*, which is when the
-compiler can’t tell at compile time which method you’re calling. In dynamic
-dispatch cases, the compiler emits code that at runtime will figure out which
-method to call.
+Recall in the [“Performance of Code Using
+Generics”][performance-of-code-using-generics]<!-- ignore --> section in
+Chapter 10 our discussion on the monomorphization process performed by the
+compiler when we use trait bounds on generics: the compiler generates
+nongeneric implementations of functions and methods for each concrete type
+that we use in place of a generic type parameter. The code that results from
+monomorphization is doing *static dispatch*, which is when the compiler knows
+what method you’re calling at compile time. This is opposed to *dynamic
+dispatch*, which is when the compiler can’t tell at compile time which method
+you’re calling. In dynamic dispatch cases, the compiler emits code that at
+runtime will figure out which method to call.
 
 When we use trait objects, Rust must use dynamic dispatch. The compiler doesn’t
 know all the types that might be used with the code that is using trait

src/ch18-01-all-the-places-for-patterns.md

@@ -28,8 +28,9 @@ value can never fail and thus covers every remaining case.
 A particular pattern `_` will match anything, but it never binds to a variable,
 so it’s often used in the last match arm. The `_` pattern can be useful when
 you want to ignore any value not specified, for example. We’ll cover the `_`
-pattern in more detail in the [“Ignoring Values in a Pattern”]
-[ignoring-values-in-a-pattern]<!-- ignore --> section later in this chapter.
+pattern in more detail in the [“Ignoring Values in a
+Pattern”][ignoring-values-in-a-pattern]<!-- ignore --> section later in this
+chapter.
 
 ### Conditional `if let` Expressions
 
@@ -229,11 +230,11 @@ error[E0308]: mismatched types
 ```
 
 If we wanted to ignore one or more of the values in the tuple, we could use `_`
-or `..`, as you’ll see in the [“Ignoring Values in a Pattern”]
-[ignoring-values-in-a-pattern]<!-- ignore --> section. If the problem is that
-we have too many variables in the pattern, the solution is to make the types
-match by removing variables so the number of variables equals the number of
-elements in the tuple.
+or `..`, as you’ll see in the [“Ignoring Values in a
+Pattern”][ignoring-values-in-a-pattern]<!-- ignore --> section. If the problem
+is that we have too many variables in the pattern, the solution is to make the
+types match by removing variables so the number of variables equals the number
+of elements in the tuple.
 
 ### Function Parameters