Remove extraneous use statement

listings/ch14-more-about-cargo/listing-14-07/add/adder/src/main.rs

@@ -1,5 +1,3 @@
-use add_one;
-
 fn main() {
     let num = 10;
     println!("Hello, world! {num} plus one is {}!", add_one::add_one(num));

src/ch06-03-if-let.md

@@ -107,7 +107,7 @@ To make this common pattern nicer to express, Rust has `let`-`else`. The
 `let`-`else` syntax takes a pattern on the left side and an expression on the
 right, very similar to `if let`, but it does not have an `if` branch, only an
 `else` branch. If the pattern matches, it will bind the value from the pattern
-in the outer scope. If the pattern does *not* match, the program will flow into
+in the outer scope. If the pattern does _not_ match, the program will flow into
 the `else` arm, which must return from the function.
 
 In Listing 6-9, you can see how Listing 6-8 looks when using `let`-`else` in

src/ch14-03-cargo-workspaces.md

@@ -149,11 +149,10 @@ Cargo doesn’t assume that crates in a workspace will depend on each other, so
 we need to be explicit about the dependency relationships.
 
 Next, let’s use the `add_one` function (from the `add_one` crate) in the
-`adder` crate. Open the _adder/src/main.rs_ file and add a `use` line at the
-top to bring the new `add_one` library crate into scope. Then change the `main`
+`adder` crate. Open the _adder/src/main.rs_ file and change the `main`
 function to call the `add_one` function, as in Listing 14-7.
 
-<Listing number="14-7" file-name="adder/src/main.rs" caption="Using the `add_one` library crate from the `adder` crate">
+<Listing number="14-7" file-name="adder/src/main.rs" caption="Using the `add_one` library crate in the `adder` crate">
 
 ```rust,ignore
 {{#rustdoc_include ../listings/ch14-more-about-cargo/listing-14-07/add/adder/src/main.rs}}

src/ch21-03-graceful-shutdown-and-cleanup.md

@@ -67,7 +67,7 @@ alternative approaches. They can make your code cleaner and less error-prone.
 
 In this case, there is a better alternative: the `Vec::drain` method. It accepts
 a range parameter to specify which items to remove from the `Vec`, and returns
-an iterator of those items. Passing the `..` range syntax will remove *every*
+an iterator of those items. Passing the `..` range syntax will remove _every_
 value from the `Vec`.
 
 So we need to update the `ThreadPool` `drop` implementation like this:
@@ -99,7 +99,7 @@ implementation and then a change in the `Worker` loop.
 First, we’ll change the `ThreadPool` `drop` implementation to explicitly drop
 the `sender` before waiting for the threads to finish. Listing 21-23 shows the
 changes to `ThreadPool` to explicitly drop `sender`. Unlike with the `workers`,
-here we *do* need to use an `Option` to be able to move `sender` out of
+here we _do_ need to use an `Option` to be able to move `sender` out of
 `ThreadPool` with `Option::take`.
 
 <Listing number="21-23" file-name="src/lib.rs" caption="Explicitly drop `sender` before joining the worker threads">