Standardize on 'adapter', not 'adaptor'

ci/dictionary.txt

@@ -2,8 +2,6 @@ personal_ws-1.1 en 0 utf-8
 abcabcabc
 abcd
 abcdefghijklmnopqrstuvwxyz
-adaptor
-adaptors
 AddAssign
 Addr
 adfb

src/ch13-02-iterators.md

@@ -111,7 +111,7 @@ trait. Some of these methods call the `next` method in their definition, which
 is why you’re required to implement the `next` method when implementing the
 `Iterator` trait.
 
-Methods that call `next` are called *consuming adaptors*, because calling them
+Methods that call `next` are called *consuming adapters*, because calling them
 uses up the iterator. One example is the `sum` method, which takes ownership of
 the iterator and iterates through the items by repeatedly calling `next`, thus
 consuming the iterator. As it iterates through, it adds each item to a running
@@ -131,17 +131,17 @@ ownership of the iterator we call it on.
 
 ### Methods that Produce Other Iterators
 
-*Iterator adaptors* are methods defined on the `Iterator` trait that don’t
+*Iterator adapters* are methods defined on the `Iterator` trait that don’t
 consume the iterator. Instead, they produce different iterators by changing
 some aspect of the original iterator.
 
-Listing 13-14 shows an example of calling the iterator adaptor method `map`,
+Listing 13-14 shows an example of calling the iterator adapter method `map`,
 which takes a closure to call on each item as the items are iterated through.
 The `map` method returns a new iterator that produces the modified items. The
 closure here creates a new iterator in which each item from the vector will be
 incremented by 1:
 
-<Listing number="13-14" file-name="src/main.rs" caption="Calling the iterator adaptor `map` to create a new iterator">
+<Listing number="13-14" file-name="src/main.rs" caption="Calling the iterator adapter `map` to create a new iterator">
 
 ```rust,not_desired_behavior
 {{#rustdoc_include ../listings/ch13-functional-features/listing-13-14/src/main.rs:here}}
@@ -156,7 +156,7 @@ However, this code produces a warning:
 ```
 
 The code in Listing 13-14 doesn’t do anything; the closure we’ve specified
-never gets called. The warning reminds us why: iterator adaptors are lazy, and
+never gets called. The warning reminds us why: iterator adapters are lazy, and
 we need to consume the iterator here.
 
 To fix this warning and consume the iterator, we’ll use the `collect` method,
@@ -181,9 +181,9 @@ on each item. This is a great example of how closures let you customize some
 behavior while reusing the iteration behavior that the `Iterator` trait
 provides.
 
-You can chain multiple calls to iterator adaptors to perform complex actions in
+You can chain multiple calls to iterator adapters to perform complex actions in
 a readable way. But because all iterators are lazy, you have to call one of the
-consuming adaptor methods to get results from calls to iterator adaptors.
+consuming adapter methods to get results from calls to iterator adapters.
 
 ### Using Closures that Capture Their Environment
 

src/ch13-03-improving-our-io-project.md

@@ -116,7 +116,7 @@ value we want to put in the `query` field of `Config`. If `next` returns a
 not enough arguments were given and we return early with an `Err` value. We do
 the same thing for the `file_path` value.
 
-### Making Code Clearer with Iterator Adaptors
+### Making Code Clearer with Iterator Adapters
 
 We can also take advantage of iterators in the `search` function in our I/O
 project, which is reproduced here in Listing 13-21 as it was in Listing 12-19:
@@ -129,14 +129,14 @@ project, which is reproduced here in Listing 13-21 as it was in Listing 12-19:
 
 </Listing>
 
-We can write this code in a more concise way using iterator adaptor methods.
+We can write this code in a more concise way using iterator adapter methods.
 Doing so also lets us avoid having a mutable intermediate `results` vector. The
 functional programming style prefers to minimize the amount of mutable state to
 make code clearer. Removing the mutable state might enable a future enhancement
 to make searching happen in parallel, because we wouldn’t have to manage
 concurrent access to the `results` vector. Listing 13-22 shows this change:
 
-<Listing number="13-22" file-name="src/lib.rs" caption="Using iterator adaptor methods in the implementation of the `search` function">
+<Listing number="13-22" file-name="src/lib.rs" caption="Using iterator adapter methods in the implementation of the `search` function">
 
 ```rust,ignore
 {{#rustdoc_include ../listings/ch13-functional-features/listing-13-22/src/lib.rs:here}}
@@ -146,7 +146,7 @@ concurrent access to the `results` vector. Listing 13-22 shows this change:
 
 Recall that the purpose of the `search` function is to return all lines in
 `contents` that contain the `query`. Similar to the `filter` example in Listing
-13-16, this code uses the `filter` adaptor to keep only the lines that
+13-16, this code uses the `filter` adapter to keep only the lines that
 `line.contains(query)` returns `true` for. We then collect the matching lines
 into another vector with `collect`. Much simpler! Feel free to make the same
 change to use iterator methods in the `search_case_insensitive` function as
@@ -158,7 +158,7 @@ The next logical question is which style you should choose in your own code and
 why: the original implementation in Listing 13-21 or the version using
 iterators in Listing 13-22. Most Rust programmers prefer to use the iterator
 style. It’s a bit tougher to get the hang of at first, but once you get a feel
-for the various iterator adaptors and what they do, iterators can be easier to
+for the various iterator adapters and what they do, iterators can be easier to
 understand. Instead of fiddling with the various bits of looping and building
 new vectors, the code focuses on the high-level objective of the loop. This
 abstracts away some of the commonplace code so it’s easier to see the concepts

src/ch13-04-performance.md

@@ -65,7 +65,7 @@ multiply the values together, sum all the results, and shift the bits in the
 sum `qlp_shift` bits to the right.
 
 Calculations in applications like audio decoders often prioritize performance
-most highly. Here, we’re creating an iterator, using two adaptors, and then
+most highly. Here, we’re creating an iterator, using two adapters, and then
 consuming the value. What assembly code would this Rust code compile to? Well,
 as of this writing, it compiles down to the same assembly you’d write by hand.
 There’s no loop at all corresponding to the iteration over the values in