Fix some typos

Author: rmehri01

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.