Backport changes to md

Author: carols10cents

nostarch/chapter14.md

@@ -1,8 +1,8 @@
 # More About Cargo and Crates.io
 
-So far we’ve used only the most basic features of Cargo to build, run, and test
-our code, but it can do a lot more. In this chapter, we’ll discuss some of its
-other, more advanced features to show you how to do the following:
+So far, we’ve used only the most basic features of Cargo to build, run, and
+test our code, but it can do a lot more. In this chapter, we’ll discuss some of
+its other, more advanced features to show you how to do the following:
 
 - Customize your build through release profiles
 - Publish libraries on [crates.io](https://crates.io/)<!-- ignore -->

nostarch/docx/chapter14.docx

@@ -6,7 +6,7 @@ various options for compiling code. Each profile is configured independently of
 the others.
 
 Cargo has two main profiles: the `dev` profile Cargo uses when you run `cargo
-build` and the `release` profile Cargo uses when you run `cargo build
+build`, and the `release` profile Cargo uses when you run `cargo build
 --release`. The `dev` profile is defined with good defaults for development,
 and the `release` profile has good defaults for release builds.
 

src/ch14-00-more-about-cargo.md

@@ -45,7 +45,7 @@ For convenience, running `cargo doc --open` will build the HTML for your
 current crate’s documentation (as well as the documentation for all of your
 crate’s dependencies) and open the result in a web browser. Navigate to the
 `add_one` function and you’ll see how the text in the documentation comments is
-rendered, as shown in Figure 14-1:
+rendered, as shown in Figure 14-1.
 
 <img alt="Rendered HTML documentation for the `add_one` function of `my_crate`" src="img/trpl14-01.png" class="center" />
 
@@ -100,20 +100,20 @@ test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; fini
 ```
 
 Now, if we change either the function or the example so the `assert_eq!` in the
-example panics and run `cargo test` again, we’ll see that the doc tests catch
+example panics, and run `cargo test` again, we’ll see that the doc tests catch
 that the example and the code are out of sync with each other!
 
 #### Commenting Contained Items
 
-The style of doc comment `//!` adds documentation to the item that contains the
-comments rather than to the items following the comments. We typically use
+The style of doc comment `//!` adds documentation to the item that *contains*
+the comments rather than to the items *following* the comments. We typically use
 these doc comments inside the crate root file (_src/lib.rs_ by convention) or
 inside a module to document the crate or the module as a whole.
 
 For example, to add documentation that describes the purpose of the `my_crate`
 crate that contains the `add_one` function, we add documentation comments that
 start with `//!` to the beginning of the _src/lib.rs_ file, as shown in Listing
-14-2:
+14-2.
 
 <Listing number="14-2" file-name="src/lib.rs" caption="Documentation for the `my_crate` crate as a whole">
 
@@ -150,14 +150,14 @@ are and might have difficulty finding the pieces they want to use if your crate
 has a large module hierarchy.
 
 In Chapter 7, we covered how to make items public using the `pub` keyword, and
-bring items into a scope with the `use` keyword. However, the structure that
-makes sense to you while you’re developing a crate might not be very convenient
-for your users. You might want to organize your structs in a hierarchy
-containing multiple levels, but then people who want to use a type you’ve
-defined deep in the hierarchy might have trouble finding out that type exists.
-They might also be annoyed at having to enter `use`
-`my_crate::some_module::another_module::UsefulType;` rather than `use`
-`my_crate::UsefulType;`.
+how to bring items into a scope with the `use` keyword. However, the structure
+that makes sense to you while you’re developing a crate might not be very
+convenient for your users. You might want to organize your structs in a
+hierarchy containing multiple levels, but then people who want to use a type
+you’ve defined deep in the hierarchy might have trouble finding out that type
+exists. They might also be annoyed at having to enter `use
+my_crate::some_module::another_module::UsefulType;` rather than `use
+my_crate::UsefulType;`.
 
 The good news is that if the structure _isn’t_ convenient for others to use
 from another library, you don’t have to rearrange your internal organization:
@@ -169,7 +169,7 @@ defined in the other location instead.
 For example, say we made a library named `art` for modeling artistic concepts.
 Within this library are two modules: a `kinds` module containing two enums
 named `PrimaryColor` and `SecondaryColor` and a `utils` module containing a
-function named `mix`, as shown in Listing 14-3:
+function named `mix`, as shown in Listing 14-3.
 
 <Listing number="14-3" file-name="src/lib.rs" caption="An `art` library with items organized into `kinds` and `utils` modules">
 
@@ -180,7 +180,7 @@ function named `mix`, as shown in Listing 14-3:
 </Listing>
 
 Figure 14-3 shows what the front page of the documentation for this crate
-generated by `cargo doc` would look like:
+generated by `cargo doc` would look like.
 
 <img alt="Rendered documentation for the `art` crate that lists the `kinds` and `utils` modules" src="img/trpl14-03.png" class="center" />
 
@@ -194,7 +194,7 @@ see them.
 Another crate that depends on this library would need `use` statements that
 bring the items from `art` into scope, specifying the module structure that’s
 currently defined. Listing 14-4 shows an example of a crate that uses the
-`PrimaryColor` and `mix` items from the `art` crate:
+`PrimaryColor` and `mix` items from the `art` crate.
 
 <Listing number="14-4" file-name="src/main.rs" caption="A crate using the `art` crate’s items with its internal structure exported">
 
@@ -215,7 +215,7 @@ module names in the `use` statements.
 
 To remove the internal organization from the public API, we can modify the
 `art` crate code in Listing 14-3 to add `pub use` statements to re-export the
-items at the top level, as shown in Listing 14-5:
+items at the top level, as shown in Listing 14-5.
 
 <Listing number="14-5" file-name="src/lib.rs" caption="Adding `pub use` statements to re-export items">
 
@@ -236,7 +236,7 @@ that lists the re-exports</span>
 
 The `art` crate users can still see and use the internal structure from Listing
 14-3 as demonstrated in Listing 14-4, or they can use the more convenient
-structure in Listing 14-5, as shown in Listing 14-6:
+structure in Listing 14-5, as shown in Listing 14-6.
 
 <Listing number="14-6" file-name="src/main.rs" caption="A program using the re-exported items from the `art` crate">
 
@@ -370,8 +370,8 @@ license = "MIT OR Apache-2.0"
 ```
 
 [Cargo’s documentation](https://doc.rust-lang.org/cargo/) describes other
-metadata you can specify to ensure others can discover and use your crate more
-easily.
+metadata you can specify to ensure that others can discover and use your crate
+more easily.
 
 ### Publishing to Crates.io
 
@@ -382,11 +382,11 @@ Publishing a crate uploads a specific version to
 
 Be careful, because a publish is _permanent_. The version can never be
 overwritten, and the code cannot be deleted except in certain circumstances.
-One major goal of [crates.io](https://crates.io/)<!-- ignore --> is to act as a
-permanent archive of code so that builds of all projects that depend on crates
-from [crates.io](https://crates.io/)<!-- ignore --> will continue to work.
-Allowing version deletions would make fulfilling that goal impossible. However,
-there is no limit to the number of crate versions you can publish.
+One major goal of Crates.io is to act as a permanent archive of code so that
+builds of all projects that depend on crates from
+[crates.io](https://crates.io/)<!-- ignore --> will continue to work. Allowing
+version deletions would make fulfilling that goal impossible. However, there is
+no limit to the number of crate versions you can publish.
 
 Run the `cargo publish` command again. It should succeed now:
 
@@ -421,7 +421,7 @@ anyone can easily add your crate as a dependency of their project.
 When you’ve made changes to your crate and are ready to release a new version,
 you change the `version` value specified in your _Cargo.toml_ file and
 republish. Use the [Semantic Versioning rules][semver] to decide what an
-appropriate next version number is based on the kinds of changes you’ve made.
+appropriate next version number is, based on the kinds of changes you’ve made.
 Then run `cargo publish` to upload the new version.
 
 <!-- Old link, do not remove -->
@@ -469,5 +469,5 @@ $ cargo yank --vers 1.0.1 --undo
 A yank _does not_ delete any code. It cannot, for example, delete accidentally
 uploaded secrets. If that happens, you must reset those secrets immediately.
 
-[spdx]: http://spdx.org/licenses/
-[semver]: http://semver.org/
+[spdx]: https://spdx.org/licenses/
+[semver]: https://semver.org/

src/ch14-01-release-profiles.md

@@ -28,7 +28,7 @@ configure the entire workspace. This file won’t have a `[package]` section.
 Instead, it will start with a `[workspace]` section that will allow us to add
 members to the workspace. We also make a point to use the latest and greatest
 version of Cargo’s resolver algorithm in our workspace by setting the
-`resolver` to `"3"`.
+`resolver` value to `"3"`.
 
 <span class="filename">Filename: Cargo.toml</span>
 
@@ -49,13 +49,13 @@ copy output below
 
 ```console
 $ cargo new adder
-    Creating binary (application) `adder` package
+     Created binary (application) `adder` package
       Adding `adder` as member of workspace at `file:///projects/add`
 ```
 
 Running `cargo new` inside a workspace also automatically adds the newly created
 package to the `members` key in the `[workspace]` definition in the workspace
-`Cargo.toml`, like this:
+_Cargo.toml_, like this:
 
 ```toml
 {{#include ../listings/ch14-more-about-cargo/output-only-01-adder-crate/add/Cargo.toml}}
@@ -100,7 +100,7 @@ copy output below
 
 ```console
 $ cargo new add_one --lib
-    Creating library `add_one` package
+     Created library `add_one` package
       Adding `add_one` as member of workspace at `file:///projects/add`
 ```
 
@@ -138,7 +138,7 @@ In the _add_one/src/lib.rs_ file, let’s add an `add_one` function:
 ```
 
 Now we can have the `adder` package with our binary depend on the `add_one`
-package that has our library. First we’ll need to add a path dependency on
+package that has our library. First, we’ll need to add a path dependency on
 `add_one` to _adder/Cargo.toml_.
 
 <span class="filename">Filename: adder/Cargo.toml</span>
@@ -154,7 +154,7 @@ 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 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 in the `adder` crate">
+<Listing number="14-7" file-name="adder/src/main.rs" caption="Using the `add_one` library crate from the `adder` crate">
 
 ```rust,ignore
 {{#rustdoc_include ../listings/ch14-more-about-cargo/listing-14-07/add/adder/src/main.rs}}
@@ -370,10 +370,11 @@ test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; fini
 This output shows `cargo test` only ran the tests for the `add_one` crate and
 didn’t run the `adder` crate tests.
 
-If you publish the crates in the workspace to [crates.io](https://crates.io/),
-each crate in the workspace will need to be published separately. Like `cargo
-test`, we can publish a particular crate in our workspace by using the `-p`
-flag and specifying the name of the crate we want to publish.
+If you publish the crates in the workspace to
+[crates.io](https://crates.io/)<!-- ignore -->, each crate in the workspace
+will need to be published separately. Like `cargo test`, we can publish a
+particular crate in our workspace by using the `-p` flag and specifying the
+name of the crate we want to publish.
 
 For additional practice, add an `add_two` crate to this workspace in a similar
 way as the `add_one` crate!

src/ch14-02-publishing-to-crates-io.md

@@ -18,7 +18,8 @@ binary target, or both.
 All binaries installed with `cargo install` are stored in the installation
 root’s _bin_ folder. If you installed Rust using _rustup.rs_ and don’t have any
 custom configurations, this directory will be *$HOME/.cargo/bin*. Ensure that
-directory is in your `$PATH`to be able to run programs you’ve installed with`cargo install`.
+directory is in your `$PATH` to be able to run programs you’ve installed with
+`cargo install`.
 
 For example, in Chapter 12 we mentioned that there’s a Rust implementation of
 the `grep` tool called `ripgrep` for searching files. To install `ripgrep`, we

src/ch14-03-cargo-workspaces.md

@@ -5,7 +5,7 @@ modify it. If a binary in your `$PATH` is named `cargo-something`, you can run
 it as if it were a Cargo subcommand by running `cargo something`. Custom
 commands like this are also listed when you run `cargo --list`. Being able to
 use `cargo install` to install extensions and then run them just like the
-built-in Cargo tools is a super convenient benefit of Cargo’s design!
+built-in Cargo tools is a super-convenient benefit of Cargo’s design!
 
 ## Summary