Fix some typos

src/asm.md

@@ -108,7 +108,7 @@ multiple output places where a `Call` only has a single return place output.
 
 Operands are lowered one more time before being passed to LLVM codegen, this is represented by the [`InlineAsmOperandRef` type][inline_asm_codegen] from `rustc_codegen_ssa`.
 
-The operands are lowered to LLVM operands and constraint codes as follow:
+The operands are lowered to LLVM operands and constraint codes as follows:
 - `out` and the output part of `inout` operands are added first, as required by LLVM. Late output
 operands have a `=` prefix added to their constraint code, non-late output operands have a `=&`
 prefix added to their constraint code.

src/borrow_check/opaque-types-region-inference-restrictions.md

@@ -229,8 +229,8 @@ fn test::{closure#0}(_upvar: &'?8 str) -> Opaque<'?6, '?7> {
 // "hidden type captures lifetime that does not appear in bounds".
 ```
 
-Without this restrictions error messages are consfusing and, more impotantly, there is a risk that
-we accept code the we would likely break in the future because member constraints are super broken
+Without this restrictions error messages are confusing and, more importantly, there is a risk that
+we accept code that would likely break in the future because member constraints are super broken
 in closures.
 
 **Output types:**

src/borrow_check/region_inference/lifetime_parameters.md

@@ -29,7 +29,7 @@ various universal regions in scope on a particular function.  We also
 create a [`UniversalRegionRelations`] struct, which tracks their
 relationships to one another. So if you have e.g. `where 'a: 'b`, then
 the [`UniversalRegionRelations`] struct would track that `'a: 'b` is
-known to hold (which could be tested with the [`outlives`] function.
+known to hold (which could be tested with the [`outlives`] function).
 
 [`UniversalRegions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/universal_regions/struct.UniversalRegions.html
 [`UniversalRegionRelations`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/type_check/free_region_relations/struct.UniversalRegionRelations.html

src/building/bootstrapping/what-bootstrapping-does.md

@@ -290,7 +290,7 @@ recently changed.
 When you build a project with `cargo`, the build artifacts for dependencies are
 normally stored in `target/debug/deps`. This only contains dependencies `cargo`
 knows about; in particular, it doesn't have the standard library. Where do `std`
-or `proc_macro` come from? They comes from the **sysroot**, the root of a number
+or `proc_macro` come from? They come from the **sysroot**, the root of a number
 of directories where the compiler loads build artifacts at runtime. The
 `sysroot` doesn't just store the standard library, though - it includes anything
 that needs to be loaded at runtime. That includes (but is not limited to):

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

@@ -394,7 +394,7 @@ space, possibly around 100GB. This is compounded if you have a separate build di
 rust-analyzer (e.g. `build-rust-analyzer`). This is easy to hit with dev-desktops which have a [set
 disk
 quota](https://github.com/rust-lang/simpleinfra/blob/8a59e4faeb75a09b072671c74a7cb70160ebef50/ansible/roles/dev-desktop/defaults/main.yml#L7)
-for each user, but this also applies to local development as well. Occassionally, you may need to:
+for each user, but this also applies to local development as well. Occasionally, you may need to:
 
 - Remove `build/` directory.
 - Remove `build-rust-analyzer/` directory (if you have a separate rust-analyzer build directory).

src/coherence.md

@@ -24,7 +24,7 @@ Overlap checks are performed for both inherent impls, and for trait impls.
 This uses the same overlap checking code, really done as two separate analyses.
 Overlap checks always consider pairs of implementations, comparing them to each other.
 
-Overlap checking for inherent impl blocks is done through `fn check_item` in coherence/inherent_impls_overlap.rs),
+Overlap checking for inherent impl blocks is done through `fn check_item` (in coherence/inherent_impls_overlap.rs),
 where you can very clearly see that (at least for small `n`), the check really performs `n^2`
 comparisons between impls. 
 

src/diagnostics.md

@@ -413,7 +413,7 @@ contexts:
 some heuristics for verbosity are met)
 - shown as a `help` sub-diagnostic with no content (used for cases where the
 suggestion is obvious from the text, but we still want to let tools to apply
-them))
+them)
 - not shown (used for _very_ obvious cases, but we still want to allow tools to
 apply them)
 

src/pat-exhaustive-checking.md

@@ -88,7 +88,7 @@ That file contains a detailed description of the algorithm.
 ### Constructors and fields
 
 In the value `Pair(Some(0), true)`, `Pair` is called the constructor of the value, and `Some(0)` and
-`true` are its fields. Every matcheable value can be decomposed in this way. Examples of
+`true` are its fields. Every matchable value can be decomposed in this way. Examples of
 constructors are: `Some`, `None`, `(,)` (the 2-tuple constructor), `Foo {..}` (the constructor for
 a struct `Foo`), and `2` (the constructor for the number `2`).
 

src/profiling/with_perf.md

@@ -263,7 +263,7 @@ What happens with `--tree-callees` is that
   to build up a call tree
 
 The `--tree-min-percent 3` option says "only show me things that take
-more than 3% of the time. Without this, the tree often gets really
+more than 3% of the time". Without this, the tree often gets really
 noisy and includes random stuff like the innards of
 malloc. `--tree-max-depth` can be useful too, it just limits how many
 levels we print.

src/tests/adding.md

@@ -196,5 +196,5 @@ These comments are very useful to others later on when your test breaks, since
 they often can highlight what the problem is. They are also useful if for some
 reason the tests need to be refactored, since they let others know which parts
 of the test were important. Often a test must be rewritten because it no longer
-tests what is was meant to test, and then it's useful to know what it *was*
+tests what it was meant to test, and then it's useful to know what it *was*
 meant to test exactly.

src/tests/running.md

@@ -30,7 +30,7 @@ notice a change) you can use the `--force-rerun` CLI option.
 
 > **Note on requirements of external dependencies**
 >
-> Some test suites may require external dependecies. This is especially true of
+> Some test suites may require external dependencies. This is especially true of
 > debuginfo tests. Some debuginfo tests require a Python-enabled gdb. You can
 > test if your gdb install supports Python by using the `python` command from
 > within gdb. Once invoked you can type some Python code (e.g. `print("hi")`)
@@ -78,7 +78,7 @@ Likewise, you can test a single file by passing its path:
 ```
 
 `x` doesn't support running a single tool test by passing its path yet. You'll
-have to use the `--test-args` argument as describled
+have to use the `--test-args` argument as described
 [below](#running-an-individual-test).
 
 ```bash

src/ty_module/binders.md

@@ -2,7 +2,7 @@
 
 Sometimes we define generic parameters not on an item but as part of a type or a where clauses. As an example the type `for<'a> fn(&'a u32)` or the where clause `for<'a> T: Trait<'a>` both introduce a generic lifetime named `'a`. Currently there is no stable syntax for `for<T>` or `for<const N: usize>` but on nightly `feature(non_lifetime_binders)` feature can be used to write where clauses (but not types) using `for<T>`/`for<const N: usize>`.
 
-The `for` is referred to as a "binder" because it brings new names into scope. In rustc we use the `Binder` type to track where these parameters are introduced and what the parameters are (i.e. how many and whether they the parameter is a type/const/region). A type such as `for<'a> fn(&'a u32)` would be
+The `for` is referred to as a "binder" because it brings new names into scope. In rustc we use the `Binder` type to track where these parameters are introduced and what the parameters are (i.e. how many and whether the parameter is a type/const/region). A type such as `for<'a> fn(&'a u32)` would be
 represented in rustc as:
 ```
 Binder(

src/ty_module/instantiating_binders.md

@@ -21,7 +21,7 @@ Unlike `EarlyBinder` we typically do not instantiate `Binder` with some concrete
 ## Instantiating with inference variables
 
 We instantiate binders with inference variables when we are trying to infer a possible instantiation of the binder, e.g. calling higher ranked function pointers or attempting to use a higher ranked where-clause to prove some bound. For example, given the `higher_ranked_fn_ptr` from the example above, if we were to call it with `&10_u32` we would: 
-- Instantaite the binder with infer vars yielding a signature of `fn(&'?0 u32) -> &'?0 u32)`
+- Instantiate the binder with infer vars yielding a signature of `fn(&'?0 u32) -> &'?0 u32)`
 - Equate the type of the provided argument `&10_u32` (&'static u32) with the type in the signature, `&'?0 u32`, inferring `'?0 = 'static`
 - The provided arguments were correct as we were successfully able to unify the types of the provided arguments with the types of the arguments in fn ptr signature
 
@@ -50,7 +50,7 @@ Note: in the original example of this chapter it was mentioned that we should no
 
 You may be wondering why we have both of these variants, afterall the data stored in `Placeholder` is effectively equivalent to that of `ReBound`: something to track which binder, and an index to track which parameter the `Binder` introduced. 
 
-The main reason for this is that `Bound` is a more syntactic representation of bound variables wheras `Placeholder` is a more semantic representation. As a concrete example:
+The main reason for this is that `Bound` is a more syntactic representation of bound variables whereas `Placeholder` is a more semantic representation. As a concrete example:
 ```rust
 impl<'a> Other<'a> for &'a u32 { }