Fix spellings

second-edition/dictionary.txt

@@ -140,6 +140,7 @@ isize
 iter
 iterator's
 JavaScript
+JoinHandle
 lang
 latin
 libc
@@ -192,6 +193,7 @@ OptionalFloatingPointNumber
 OptionalNumber
 OsStr
 OsString
+other's
 overread
 parameterize
 ParseIntError
@@ -224,6 +226,7 @@ repr
 retweet
 ripgrep
 runtime
+runtimes
 Rustacean
 Rustaceans
 rustc
@@ -261,6 +264,7 @@ submodule
 submodules
 Submodules
 suboptimal
+substring
 subtree
 subtyping
 Summarizable
@@ -296,6 +300,7 @@ USERPROFILE
 usize
 UsState
 utils
+vals
 variable's
 variant's
 vers

second-edition/src/ch11-01-writing-tests.md

@@ -229,7 +229,7 @@ helps us check that our code is functioning in the way we intend.
 <!-- what kind of thing can be passed as an argument? Presumably when we use it
 for real we won't pass it `true` or `false` as an argument, but some condition
 that will evaluate to true or false? In which case, should below be phrased "If
-the argument evaluates to true" and an exaplanation of that? Or maybe even a
+the argument evaluates to true" and an explanation of that? Or maybe even a
 working example would be better, this could be misleading -->
 <!-- We were trying to really break it down, to show just how the `assert!`
 macro works and what it looks like for it to pass or fail, before we got into

second-edition/src/ch11-02-running-tests.md

@@ -34,7 +34,7 @@ For example, say each of your tests runs some code that creates a file on disk
 named `test-output.txt` and writes some data to that file. Then each test reads
 the data in that file and asserts that the file contains a particular value,
 which is different in each test. Because the tests are all run at the same
-time, one test might overrwrite the file between when another test writes and
+time, one test might overwrite the file between when another test writes and
 reads the file. The second test will then fail, not because the code is
 incorrect, but because the tests have interfered with each other while running
 in parallel. One solution would be to make sure each test writes to a different
@@ -275,7 +275,7 @@ fn expensive_test() {
 }
 ```
 
-We add the `#[ignore]` line to the test we want to exlcude, after `#[test]`.
+We add the `#[ignore]` line to the test we want to exclude, after `#[test]`.
 Now if we run our tests, we'll see `it_works` runs, but `expensive_test` does
 not:
 

second-edition/src/ch11-03-test-organization.md

@@ -47,7 +47,7 @@ mod tests {
 ```
 
 This is the automatically generated test module. The attribute `cfg` stands for
-*configruation*, and tells Rust that the following item should only be included
+*configuration*, and tells Rust that the following item should only be included
 given a certain configuration. In this case, the configuration is `test`,
 provided by Rust for compiling and running tests. By using this attribute,
 Cargo only compiles our test code if we actively run the tests with `cargo

second-edition/src/ch16-01-threads.md

@@ -114,7 +114,7 @@ to take a break and give the other thread a turn.
 
 Not only does the code in Listing 16-1 not allow the spawned thread to finish
 most of the time since the main thread ends before the spawned thread is done,
-there's actualy no guarantee that the spawned thread will get to run at all! We
+there's actually no guarantee that the spawned thread will get to run at all! We
 can fix this by saving the return value of `thread::spawn`, which is a
 `JoinHandle`. That looks like Listing 16-2:
 

second-edition/src/ch16-04-extensible-concurrency-sync-and-send.md

@@ -70,7 +70,7 @@ Chapter 20 will use these concepts in a more realistic situation than the
 smaller examples we discussed in this chapter.
 
 As we mentioned, since very little of how Rust deals with concurrency has to be
-part of the language, there are many concurrency solutions implemnted as
+part of the language, there are many concurrency solutions implemented as
 crates. These evolve more quickly than the standard library; search online for
 the current state-of-the-art crates for use in multithreaded situations.