Fancy quotes

src/ch07-01-packages-and-crates.md

@@ -8,10 +8,10 @@ package contains a *Cargo.toml* file that describes how to build those crates.
 A *crate* can be a binary crate or a library crate. *Binary crates* are
 programs you can compile to an executable that you can run, such as a
 command-line program or a server. They must have a function called `main` that
-defines what happens when the executable runs. All the crates we've created so
+defines what happens when the executable runs. All the crates we’ve created so
 far have been binary crates.
 
-*Library crates* don't have a `main` function, and they don't compile to an
+*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][rand]<!-- ignore
 --> provides functionality that generates random numbers.

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

@@ -11,22 +11,22 @@ detail.
 
 ### Modules Quick Reference
 
-Here's how modules, paths, the `use` keyword, and the `pub` keyword work in the
-compiler, and how most developers organize their code. We'll be going through
+Here’s how modules, paths, the `use` keyword, and the `pub` keyword work in the
+compiler, and how most developers organize their code. We’ll be going through
 examples of each of these rules, but this is a great place to look in the
 future as a reminder of how modules 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).
 - **Declaring modules**: In the crate root file, you can declare a new module
-  named, say, "garden", with `mod garden;`. The compiler will look for the code
+  named, say, “garden”, with `mod garden;`. The compiler will look for the code
   inside the module in these places:
   - Inline, directly following `mod garden`, within curly brackets instead of
     the semicolon
   - In the file *src/garden.rs*
   - In the file *src/garden/mod.rs*
-- **Declaring submodules**: In any file other than the crate root that's being
+- **Declaring submodules**: In any file other than the crate root that’s being
   compiled as part of the crate (for example, *src/garden.rs*), you can declare
   submodules (for example, `mod vegetables;`). The compiler will look for the
   code inside submodules in these places within a directory named for the
@@ -50,8 +50,8 @@ future as a reminder of how modules work.
   crate::garden::vegetables::Asparagus;` and then only need to write `Asparagus`
   to make use of that type in the scope.
 
-Here's a binary crate named `backyard` that illustrates these rules. The
-crate's directory, also named `backyard`, contains these files and directories:
+Here’s a binary crate named `backyard` that illustrates these rules. The
+crate’s directory, also named `backyard`, contains these files and directories:
 
 ```text
 backyard
@@ -88,7 +88,7 @@ included too:
 {{#rustdoc_include ../listings/ch07-managing-growing-projects/quick-reference-example/src/garden/vegetables.rs}}
 ```
 
-Now let's get into the details of these rules and demonstrate them in action!
+Now let’s get into the details of these rules and demonstrate them in action!
 
 ### Grouping Related Code in Modules
 

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

@@ -63,7 +63,7 @@ would still be valid. However, if we moved the `eat_at_restaurant` function
 separately into a module named `dining`, the absolute path to the
 `add_to_waitlist` call would stay the same, but the relative path would need to
 be updated. Our preference is to specify absolute paths because it’s more
-likely we'll want to move code definitions and item calls independently of each
+likely we’ll want to move code definitions and item calls independently of each
 other.
 
 Let’s try to compile Listing 7-3 and find out why it won’t compile yet! The
@@ -177,7 +177,7 @@ If you plan on sharing your library crate so other projects can use your code,
 your public API is your contract with users of your crate about how they
 interact with your code. There are many considerations around managing changes
 to your public API to make it easier for people to depend on your crate. These
-considerations are out of the scope of this book; if you're interested in this
+considerations are out of the scope of this book; if you’re interested in this
 topic, see [The Rust API Guidelines][api-guidelines].
 
 > #### Best Practices for Packages with a Binary and a Library
@@ -187,17 +187,17 @@ topic, see [The Rust API Guidelines][api-guidelines].
 > package name by default. Typically, packages with this pattern will have just
 > enough code in the binary crate to start an executable that calls code with
 > the library crate. This lets other projects benefit from the most
-> functionality that the package provides, because the library crate's code can
+> functionality that the package provides, because the library crate’s code can
 > be shared.
 >
 > The module tree should be defined in *src/lib.rs*. Then, any public items can
 > be used in the binary crate by starting paths with the name of the package.
 > The binary crate becomes a user of the library crate just like a completely
 > external crate would use the library crate: it can only use the public API.
-> This helps you design a good API; not only are you the author, you're also a
+> This helps you design a good API; not only are you the author, you’re also a
 > client!
 >
-> In [Chapter 12][ch12]<!-- ignore -->, we'll demonstrate this organizational
+> In [Chapter 12][ch12]<!-- ignore -->, we’ll demonstrate this organizational
 > practice with a command-line program that will contain both a binary crate
 > and a library crate.
 

src/ch07-04-bringing-paths-into-scope-with-the-use-keyword.md

@@ -31,7 +31,7 @@ also check privacy, like any other paths.
 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`
-statement and the function body won't compile:
+statement and the function body won’t compile:
 
 <span class="filename">Filename: src/lib.rs</span>
 
@@ -40,7 +40,7 @@ statement and the function body won't compile:
 ```
 
 <span class="caption">Listing 7-12: A `use` statement only applies in the scope
-it's in</span>
+it’s in</span>
 
 The compiler error shows that the shortcut no longer applies within the
 `customer` module:
@@ -49,7 +49,7 @@ The compiler error shows that the shortcut no longer applies within the
 {{#include ../listings/ch07-managing-growing-projects/listing-07-12/output.txt}}
 ```
 
-Notice there's also a warning that the `use` is no longer used in its scope! To
+Notice there’s also a warning that the `use` is no longer used in its scope! To
 fix this problem, move the `use` within the `customer` module too, or reference
 the shortcut in the parent module with `super::hosting` within the child
 `customer` module.

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

@@ -9,10 +9,10 @@ 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
 binary crates whose crate root file is *src/main.rs*.
 
-First, we'll extract the `front_of_house` module to its own file. Remove the
+First, we’ll extract the `front_of_house` module to its own file. Remove the
 code inside the curly brackets for the `front_of_house` module, leaving only
 the `mod front_of_house;` declaration, so that *src/lib.rs* contains the code
-shown in Listing 7-21. Note that this won't compile until we create the
+shown in Listing 7-21. Note that this won’t compile until we create the
 *src/front_of_house.rs* file in Listing 7-22.
 
 <span class="filename">Filename: src/lib.rs</span>
@@ -41,13 +41,13 @@ module in *src/front_of_house.rs*</span>
 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
+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”][paths]<!-- ignore --> section. In other words, `mod` is *not* an
-"include" operation that other programming languages have.
+“include” operation that other programming languages have.
 
-Next, we'll extract the `hosting` module to its own file as well. The process
+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
 of the root module. The file for `hosting` will be in a directory named for its
 place in the module tree.
@@ -74,7 +74,7 @@ Then we create a *src/front_of_house* directory and a file
 If we instead put *hosting.rs* in the *src* directory, the compiler would
 expect that code to be in a `hosting` module declared in the crate root, not as
 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
+what files to look in for modules’ code means the directories and files more
 closely match the module tree.
 
 > ### Alternate File Paths
@@ -83,26 +83,26 @@ closely match the module tree.
 > but an older file path is also still supported.
 >
 > For a module named `front_of_house` declared in the crate root, the compiler
-> will look for the module's code in:
+> will look for the module’s code in:
 >
 > * *src/front_of_house.rs* (what we covered)
 > * *src/front_of_house/mod.rs* (older, still supported path)
 >
 > For a module named `hosting` that is a submodule of `front_of_house`, the
-> compiler will look for the module's code in:
+> compiler will look for the module’s code in:
 >
 > * *src/front_of_house/hosting.rs* (what we covered)
 > * *src/front_of_house/hosting/mod.rs* (older, still supported path)
 >
-> If you use both for the same module, you'll get a compiler error. Using
+> If you use both for the same module, you’ll get a compiler error. Using
 > different 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
 > project can end up with many files named *mod.rs*, which can get confusing
 > when you have them open in your editor at the same time.
 
-Moving each module's code to a separate file is now complete, and the module
+Moving each module’s code to a separate file is now complete, and the module
 tree remains the same. The function calls in `eat_at_restaurant` will work
 without any modification, even though the definitions live in different files.
 This technique lets you move modules to new files as they grow in size.