Propagate ch7 tech review edits to src

src/ch07-02-defining-modules-to-control-scope-and-privacy.md

@@ -19,12 +19,12 @@ work.
 
 - **Start from the crate root**: When compiling a crate, the compiler first
   looks in the crate root file (usually *src/lib.rs* for a library crate or
-  *src/main.rs* for a binary crate).
+  *src/main.rs* for a binary crate) for code to compile.
 - **Declaring modules**: In the crate root file, you can declare new modules;
 say, you declare a “garden” module with `mod garden;`. The compiler will look
 for the module’s code in these places:
-  - Inline, directly following `mod garden`, within curly brackets instead of
-    the semicolon
+  - Inline, within curly brackets that replace the semicolon following `mod
+    garden`
   - In the file *src/garden.rs*
   - In the file *src/garden/mod.rs*
 - **Declaring submodules**: In any file other than the crate root, you can

src/ch07-03-paths-for-referring-to-an-item-in-the-module-tree.md

@@ -18,12 +18,16 @@ separated by double colons (`::`).
 Returning to Listing 7-1, say we want to call the `add_to_waitlist` function.
 This is the same as asking: what’s the path of the `add_to_waitlist` function?
 Listing 7-3 contains Listing 7-1 with some of the modules and functions
-removed. We’ll show two ways to call the `add_to_waitlist` function from a new
-function `eat_at_restaurant` defined in the crate root. The `eat_at_restaurant`
-function is part of our library crate’s public API, so we mark it with the
-`pub` keyword. In the [“Exposing Paths with the `pub` Keyword”][pub]<!-- ignore
---> section, we’ll go into more detail about `pub`. Note that this example
-won’t compile just yet; we’ll explain why in a bit.
+removed.
+
+We’ll show two ways to call the `add_to_waitlist` function from a new function
+`eat_at_restaurant` defined in the crate root. These paths are correct, but
+there’s another problem remaining that will prevent this example from compiling
+as-is. We’ll explain why in a bit.
+
+The `eat_at_restaurant` function is part of our library crate’s public API, so
+we mark it with the `pub` keyword. In the [“Exposing Paths with the `pub`
+Keyword”][pub]<!-- ignore --> section, we’ll go into more detail about `pub`.
 
 <span class="filename">Filename: src/lib.rs</span>
 
@@ -199,10 +203,11 @@ interested in this topic, see [The Rust API Guidelines][api-guidelines].
 
 We can construct relative paths that begin in the parent module, rather than
 the current module or the crate root, by using `super` at the start of the
-path. This is like starting a filesystem path with the `..` syntax. This allows
-us to reference an item that we know is in the parent module, which can make
-rearranging the module tree easier when the module is closely related to the
-parent, but the parent might be moved elsewhere in the module tree someday.
+path. This is like starting a filesystem path with the `..` syntax. Using
+`super` allows us to reference an item that we know is in the parent module,
+which can make rearranging the module tree easier when the module is closely
+related to the parent, but the parent might be moved elsewhere in the module
+tree someday.
 
 Consider the code in Listing 7-8 that models the situation in which a chef
 fixes an incorrect order and personally brings it out to the customer. The

src/ch07-05-separating-modules-into-different-files.md

@@ -94,7 +94,7 @@ directories and files more closely match the module tree.
 > * *src/front_of_house/hosting/mod.rs* (older style, still supported path)
 >
 > If you use both styles for the same module, you’ll get a compiler error. Using
-> both styles for different modules in the same project is allowed, but
+> a mix of both styles for different modules in the same project is allowed, but
 > might be confusing for people navigating your project.
 >
 > The main downside to the style that uses files named *mod.rs* is that your