Fix miscellaneous spelling typos.

src/SUMMARY.md

@@ -81,7 +81,7 @@
             - [Member constraints](./borrow_check/region_inference/member_constraints.md)
             - [Placeholders and universes][pau]
             - [Closure constraints](./borrow_check/region_inference/closure_constraints.md)
-            - [Errror reporting](./borrow_check/region_inference/error_reporting.md)
+            - [Error reporting](./borrow_check/region_inference/error_reporting.md)
         - [Two-phase-borrows](./borrow_check/two_phase_borrows.md)
     - [Constant evaluation](./const-eval.md)
         - [miri const evaluator](./miri.md)

src/appendix/glossary.md

@@ -8,7 +8,7 @@ Term                    | Meaning
 ------------------------|--------
 AST                     |  the abstract syntax tree produced by the syntax crate; reflects user syntax very closely.
 binder                  |  a "binder" is a place where a variable or type is declared; for example, the `<T>` is a binder for the generic type parameter `T` in `fn foo<T>(..)`, and \|`a`\|` ...` is a binder for the parameter `a`. See [the background chapter for more](./background.html#free-vs-bound)
-bound variable          |  a "bound variable" is one that is declared within an expression/term. For example, the variable `a` is bound within the closure expession \|`a`\|` a * 2`. See [the background chapter for more](./background.html#free-vs-bound)
+bound variable          |  a "bound variable" is one that is declared within an expression/term. For example, the variable `a` is bound within the closure expression \|`a`\|` a * 2`. See [the background chapter for more](./background.html#free-vs-bound)
 codegen                 |  the code to translate MIR into LLVM IR.
 codegen unit            |  when we produce LLVM IR, we group the Rust code into a number of codegen units. Each of these units is processed by LLVM independently from one another, enabling parallelism. They are also the unit of incremental re-use.
 completeness            |  completeness is a technical term in type theory. Completeness means that every type-safe program also type-checks. Having both soundness and completeness is very hard, and usually soundness is more important. (see "soundness").

src/borrow_check/region_inference.md

@@ -217,7 +217,7 @@ Here are some of the fields of the struct:
 - [`type_tests`]: contains some constraints on types that we must check after
   inference (e.g. `T: 'a`).
 - [`closure_bounds_mapping`]: used for propagating region constraints from
-  closures back out to the creater of the closure.
+  closures back out to the creator of the closure.
 
 [`constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#structfield.constraints
 [`liveness_constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#structfield.liveness_constraints

src/closure.md

@@ -121,7 +121,7 @@ the *free variables* meaning they are not bound to the context of the closure.
 
 Other than lazy invocation, one other thing that the distinguishes a closure from a
 normal function is that it can use the upvars. It borrows these upvars from its surrounding
-context; therfore the compiler has to determine the upvar's borrow type. The compiler starts with
+context; therefore the compiler has to determine the upvar's borrow type. The compiler starts with
 assigning an immutable borrow type and lowers the restriction (that is, changes it from
 **immutable** to **mutable** to **move**) as needed, based on the usage. In the Example 1 above, the
 closure only uses the variable for printing but does not modify it in any way and therefore, in the

src/codegen/updating-llvm.md

@@ -24,7 +24,7 @@ another:
   them upstream in LLVM. We'll want to pull fixes back to the compiler itself as
   they're merged upstream.
 
-* Second, a new feature may be avaiable in LLVM that we want to use in rustc,
+* Second, a new feature may be available in LLVM that we want to use in rustc,
   but we don't want to wait for a full LLVM release to test it out.
 
 Each of these reasons has a different strategy for updating LLVM, and we'll go

src/how-to-build-and-run.md

@@ -495,12 +495,12 @@ One of the challenges with rustc is that the RLS can't handle it, since it's a
 bootstrapping compiler. This makes code navigation difficult. One solution is to
 use `ctags`.
 
-`ctags` has a long history and several variants. Exhuberant CTags seems to be
+`ctags` has a long history and several variants. Exuberant Ctags seems to be
 quite commonly distributed but it does not have out-of-box Rust support. Some
 distributions seem to use [Universal Ctags][utags], which is a maintained fork
 and does have built-in Rust support.
 
-The following script can be used to set up Exhuberant Ctags:
+The following script can be used to set up Exuberant Ctags:
 [https://github.com/nikomatsakis/rust-etags][etags].
 
 `ctags` integrates into emacs and vim quite easily. The following can then be

src/kinds.md

@@ -30,7 +30,7 @@ make use of the safe [`UnpackedKind`](#unpackedkind) abstraction.
 As `Kind` itself is not type-safe, the `UnpackedKind` enum provides a more
 convenient and safe interface for dealing with kinds. An `UnpackedKind` can
 be converted to a raw `Kind` using `Kind::from()` (or simply `.into()` when
-the context is clear). As mentioned earlier, substition lists store raw
+the context is clear). As mentioned earlier, substitution lists store raw
 `Kind`s, so before dealing with them, it is preferable to convert them to
 `UnpackedKind`s first. This is done by calling the `.unpack()` method.
 

src/traits/goals-and-clauses.md

@@ -53,7 +53,7 @@ In terms of code, these types are defined in
 definitions given above, general goals basically consist in a combination of
 domain goals.
 
-Moreover, flattenning a bit the definition of clauses given previously, one can
+Moreover, flattening a bit the definition of clauses given previously, one can
 see that clauses are always of the form:
 ```text
 forall<K1, ..., Kn> { DomainGoal :- Goal }

src/traits/implied-bounds.md

@@ -81,7 +81,7 @@ The rationale for implied bounds for traits is that if a type implements
 `Copy`, that is, if there exists an `impl Copy` for that type, there *ought*
 to exist an `impl Clone` for that type, otherwise the compiler would have
 reported an error in the first place. So again, if we were forced to repeat the
-additionnal `where SomeType: Clone` everywhere whereas we already know that
+additional `where SomeType: Clone` everywhere whereas we already know that
 `SomeType: Copy` hold, we would kind of duplicate the verification work.
 
 Implied bounds are not yet completely enforced in rustc, at the moment it only