Change more places we say "import" to say "bring into scope"

I've noted all of these in the PDF we're sending to nostarch containing
small changes.

2018-edition/src/appendix-01-keywords.md

@@ -46,7 +46,7 @@ The following keywords currently have the functionality described.
 * `true` - Boolean true literal
 * `type` - define a type alias or associated type
 * `unsafe` - denote unsafe code, functions, traits, or implementations
-* `use` - import symbols into scope
+* `use` - bring symbols into scope
 * `where` - denote clauses that constrain a type
 * `while` - loop conditionally based on the result of an expression
 

2018-edition/src/ch09-02-recoverable-errors-with-result.md

@@ -114,8 +114,8 @@ fn main() {
 `Result` variants that might be returned</span>
 
 Note that, like the `Option` enum, the `Result` enum and its variants have been
-imported in the prelude, so we don’t need to specify `Result::` before the `Ok`
-and `Err` variants in the `match` arms.
+brought into scope by the prelude, so we don’t need to specify `Result::`
+before the `Ok` and `Err` variants in the `match` arms.
 
 Here we tell Rust that when the result is `Ok`, return the inner `file` value
 out of the `Ok` variant, and we then assign that file handle value to the

2018-edition/src/ch10-02-traits.md

@@ -130,7 +130,7 @@ Note that because we defined the `Summary` trait and the `NewsArticle` and
 scope. Let’s say this *lib.rs* is for a crate we’ve called `aggregator` and
 someone else wants to use our crate’s functionality to implement the `Summary`
 trait on a struct defined within their library’s scope. They would need to
-import the trait into their scope first. They would do so by specifying `use
+bring the trait into their scope first. They would do so by specifying `use
 aggregator::Summary;`, which then would enable them to implement `Summary` for
 their type. The `Summary` trait would also need to be a public trait for
 another crate to implement it, which it is because we put the `pub` keyword
@@ -314,7 +314,7 @@ pub fn notify<T: Summary>(item1: T, item2: T) {
 #### Specify multiple traits with `+`
 
 If `notify` needed to display formatting on `item`, as well as use the `summarize`
-method, then `item` would need to implement two different traits at the same time: 
+method, then `item` would need to implement two different traits at the same time:
 `Display` and `Summary`. This can be done using the `+` syntax:
 
 ```rust,ignore

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

@@ -92,7 +92,7 @@ mod tests {
 
 Note that the `internal_adder` function is not marked as `pub`, but because
 tests are just Rust code and the `tests` module is just another module, you can
-import and call `internal_adder` in a test just fine. If you don’t think
+bring `internal_adder` into a test's scope and call it. If you don’t think
 private functions should be tested, there’s nothing in Rust that will compel
 you to do so.
 
@@ -133,7 +133,7 @@ fn it_adds_two() {
 
 We’ve added `use adder` at the top of the code, which we didn’t need in the
 unit tests. The reason is that each test in the `tests` directory is a separate
-crate, so we need to import our library into each of them.
+crate, so we need to bring our library into each test crate's scope.
 
 We don’t need to annotate any code in *tests/integration_test.rs* with
 `#[cfg(test)]`. Cargo treats the `tests` directory specially and compiles files
@@ -299,14 +299,14 @@ we demonstrated in Listing 7-4. Then in the test function, we can call the
 
 If our project is a binary crate that only contains a *src/main.rs* file and
 doesn’t have a *src/lib.rs* file, we can’t create integration tests in the
-*tests* directory and use `use` to import functions defined in the
-*src/main.rs* file. Only library crates expose functions that other crates can
-call and use; binary crates are meant to be run on their own.
+*tests* directory and bring functions defined in the *src/main.rs* file into
+scope with a `use` statement. Only library crates expose functions that other
+crates can use; binary crates are meant to be run on their own.
 
 This is one of the reasons Rust projects that provide a binary have a
 straightforward *src/main.rs* file that calls logic that lives in the
 *src/lib.rs* file. Using that structure, integration tests *can* test the
-library crate by using `use` to make the important functionality available.
+library crate with `use` to make the important functionality available.
 If the important functionality works, the small amount of code in the
 *src/main.rs* file will work as well, and that small amount of code doesn’t
 need to be tested.

2018-edition/src/ch12-03-improving-error-handling-and-modularity.md

@@ -423,13 +423,13 @@ case is the static string `not enough arguments` that we added in Listing 12-9,
 to our closure in the argument `err` that appears between the vertical pipes.
 The code in the closure can then use the `err` value when it runs.
 
-We’ve added a new `use` line to import `process` from the standard library. The
-code in the closure that will be run in the error case is only two lines: we
-print the `err` value and then call `process::exit`. The `process::exit`
-function will stop the program immediately and return the number that was
-passed as the exit status code. This is similar to the `panic!`-based handling
-we used in Listing 12-8, but we no longer get all the extra output. Let’s try
-it:
+We’ve added a new `use` line to bring `process` from the standard library into
+scope. The code in the closure that will be run in the error case is only two
+lines: we print the `err` value and then call `process::exit`. The
+`process::exit` function will stop the program immediately and return the
+number that was passed as the exit status code. This is similar to the
+`panic!`-based handling we used in Listing 12-8, but we no longer get all the
+extra output. Let’s try it:
 
 ```text
 $ cargo run

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

@@ -235,9 +235,9 @@ front page, nor is the `mix` function. We have to click `kinds` and `utils` to
 see them.
 
 Another crate that depends on this library would need `use` statements that
-import the items from `art`, 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:
+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:
 
 <span class="filename">Filename: src/main.rs</span>
 

2018-edition/src/ch15-03-drop.md

@@ -50,8 +50,8 @@ fn main() {
 <span class="caption">Listing 15-14: A `CustomSmartPointer` struct that
 implements the `Drop` trait where we would put our cleanup code</span>
 
-The `Drop` trait is included in the prelude, so we don’t need to import it. We
-implement the `Drop` trait on `CustomSmartPointer` and provide an
+The `Drop` trait is included in the prelude, so we don’t need to bring it into
+scope. We implement the `Drop` trait on `CustomSmartPointer` and provide an
 implementation for the `drop` method that calls `println!`. The body of the
 `drop` function is where you would place any logic that you wanted to run when
 an instance of your type goes out of scope. We’re printing some text here to

2018-edition/src/ch19-06-macros.md

@@ -97,8 +97,8 @@ definition</span>
 > is an optimization that we don’t include here to make the example simpler.
 
 The `#[macro_export]` annotation indicates that this macro should be made
-available whenever the crate in which we’re defining the macro is imported.
-Without this annotation, the macro can't be brought into scope.
+available whenever the crate in which we’re defining the macro is brought into
+scope. Without this annotation, the macro can't be brought into scope.
 
 We then start the macro definition with `macro_rules!` and the name of the
 macro we’re defining *without* the exclamation mark. The name, in this case