Fix nostarch snapshot

nostarch/chapter07.md

@@ -1,3 +1,9 @@
+<!-- DO NOT EDIT THIS FILE.
+
+This file is periodically generated from the content in the `/src/`
+directory, so all fixes need to be made in `/src/`.
+-->
+
 [TOC]
 
 # Managing Growing Projects with Packages, Crates, and Modules
@@ -50,6 +56,8 @@ understanding of the module system and be able to work with scopes like a pro!
 
 ## Packages and Crates
 
+<!-- Liz: I reorganized this section a little bit. /Carol -->
+
 The first parts of the module system we’ll cover are packages and crates.
 
 A *package* is one or more crates that provide a set of functionality. A
@@ -63,17 +71,16 @@ far have been binary crates.
 
 *Library crates* don’t have a `main` function, and they don’t compile to an
 executable. They define functionality intended to be shared with multiple
-projects. For example, the `rand` crate we used in Chapter 2 provides functionality that generates random numbers.
+projects. For example, the `rand` crate we used in Chapter 2 provides
+functionality that generates random numbers.
 
 The *crate root* is a source file that the Rust compiler starts from and makes
 up the root module of your crate (we’ll explain modules in depth in the
-“Defining Modules to Control Scope and Privacy”
-section).
+“Defining Modules to Control Scope and Privacy” section).
 
-Several rules determine what a package can contain. A package can contain
-at most one library crate. It can contain as many binary crates
-as you’d like, but it must contain at least one crate (either library or
-binary).
+Several rules determine what a package can contain. A package can contain at
+most one library crate. It can contain as many binary crates as you’d like, but
+it must contain at least one crate (either library or binary).
 
 Let’s walk through what happens when we create a package. First, we enter the
 command `cargo new`:
@@ -589,9 +596,9 @@ I wanted to add a bit of a call-out for. /Carol -->
 > This helps you design a good API; not only are you the author, you’re also a
 > client!
 >
-> In Chapter 12, we’ll demonstrate this organizational
-> practice with a command-line program that will contain both a binary crate
-> and a library crate.
+> In Chapter 12, we’ll demonstrate this organizational practice with a
+> command-line program that will contain both a binary crate and a library
+> crate.
 
 ### Starting Relative Paths with `super`
 
@@ -762,6 +769,10 @@ root, `hosting` is now a valid name in that scope, just as though the `hosting`
 module had been defined in the crate root. Paths brought into scope with `use`
 also check privacy, like any other paths.
 
+<!-- Liz: This next example is new and demonstrates something readers reported
+having issues with. The previous Listing 7-12 didn't feel like it was pulling
+its weight. /Carol -->
+
 Note that `use` only creates the shortcut for the particular scope in which the
 `use` occurs. Listing 7-12 moves the `eat_at_restaurant` function into a new
 child module named `customer`, which is then a different scope than the `use`
@@ -791,8 +802,6 @@ The compiler error shows that the shortcut no longer applies within the
 `customer` module:
 
 ```
-$ cargo build
-   Compiling restaurant v0.1.0 (file:///projects/restaurant)
 error[E0433]: failed to resolve: use of undeclared crate or module `hosting`
   --> src/lib.rs:11:9
    |
@@ -806,10 +815,6 @@ warning: unused import: `crate::front_of_house::hosting`
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: `#[warn(unused_imports)]` on by default
-
-For more information about this error, try `rustc --explain E0433`.
-warning: `restaurant` (lib) generated 1 warning
-error: could not compile `restaurant` due to previous error; 1 warning emitted
 ```
 
 Notice there’s also a warning that the `use` is no longer used in its scope! To
@@ -983,12 +988,6 @@ In Chapter 2, we programmed a guessing game project that used an external
 package called `rand` to get random numbers. To use `rand` in our project, we
 added this line to *Cargo.toml*:
 
-<!-- When updating the version of `rand` used, also update the version of
-`rand` used in these files so they all match:
-* ch02-00-guessing-game-tutorial.md
-* ch14-03-cargo-workspaces.md
--->
-
 Filename: Cargo.toml
 
 ```
@@ -1121,6 +1120,11 @@ So far, all the examples in this chapter defined multiple modules in one file.
 When modules get large, you might want to move their definitions to a separate
 file to make the code easier to navigate.
 
+<!-- Liz: I tweaked the explanation of how and where to move the code around in
+this section a bit; some readers ended up with code that didn't compile because
+the last explanation wasn't as clear as it could have been. Please do try
+following these instructions! /Carol -->
+
 For example, let’s start from the code in Listing 7-17 and extract modules into
 files instead of having all the modules defined in the crate root file. In this
 case, the crate root file is *src/lib.rs*, but this procedure also works with
@@ -1163,14 +1167,20 @@ pub mod hosting {
 Listing 7-22: Definitions inside the `front_of_house` module in
 *src/front_of_house.rs*
 
+<!-- Liz: This next paragraph calls out a frequent problem people have when
+they assume Rust works like other programming languages they're already
+familiar with. Let me know if you think this is a good place for this or if it
+would fit better somewhere else? And if it seems like it would still make sense
+whether or not you're personally having this problem? /Carol -->
+
 Note that you only need to load the contents of a file using a `mod`
 declaration once somewhere in your module tree. Once the compiler knows the
 file is part of the project (and knows where in the module tree the code
 resides because of where you’ve put the `mod` statement), other files in your
 project should refer to the code in that file using a path to where it was
-declared as covered in the “Paths for Referring to an Item in the Module
-Tree” section. In other words, `mod` is *not* an
-“include” operation that other programming languages have.
+declared as covered in the “Paths for Referring to an Item in the Module Tree”
+section. In other words, `mod` is *not* an “include” operation that other
+programming languages have.
 
 Next, we’ll extract the `hosting` module to its own file as well. The process
 is a bit different because `hosting` is a child module of `front_of_house`, not
@@ -1202,6 +1212,10 @@ a child of the `front_of_house` module. The rules the compiler follows to know
 what files to look in for modules’ code means the directories and files more
 closely match the module tree.
 
+<!-- Liz: This new box is a topic some readers were surprised wasn't covered at
+all, so I wanted to put in a quick mention because some people prefer this
+structure even though it's not what most projects do. /Carol -->
+
 > ### Alternate File Paths
 >
 > This section covered the most idiomatic file paths the Rust compiler uses;