Fixes some typos

src/backend/monomorph.md

@@ -70,7 +70,7 @@ or more modules in Crate B.
 | Crate A function | Behavior |
 | - | - |
 | Non-generic function | Crate A function doesn't appear in any codegen units of Crate B |
-| Non-generic `#[inline]` function |  Crate A function appears with in a single CGU  of Crate B, and exists even after post-inlining stage|
+| Non-generic `#[inline]` function |  Crate A function appears within a single CGU  of Crate B, and exists even after post-inlining stage|
 | Generic function |  Regardless of inlining, all monomorphized (specialized) functions <br> from Crate A appear within a single codegen unit for Crate B. <br> The codegen unit exists even after the post inlining stage.|
 | Generic `#[inline]` function |   - same - |
 

src/macro-expansion.md

@@ -149,9 +149,9 @@ macros are implemented in [`rustc_builtin_macros`], along with some other early
 code generation facilities like injection of standard library imports or
 generation of test harness. There are some additional helpers for building
 their AST fragments in [`rustc_expand::build`][reb]. Eager expansion generally
-performs a subset of the things that lazy (normal) expansion. It is done by
+performs a subset of the things that lazy (normal) expansion does. It is done by
 invoking [`fully_expand_fragment`][fef] on only part of a crate (as opposed to
-whole crate, like we normally do).
+the whole crate, like we normally do).
 
 ### Other Data Structures
 
@@ -532,7 +532,7 @@ three cases has occurred:
 - Failure: the token stream does not match `matcher`. This results in an error message such as
   "No rule expected token _blah_".
 - Error: some fatal error has occurred _in the parser_. For example, this
-  happens if there are more than one pattern match, since that indicates
+  happens if there is more than one pattern match, since that indicates
   the macro is ambiguous.
 
 The full interface is defined [here][code_parse_int].

src/mir/dataflow.md

@@ -61,7 +61,7 @@ slower as a result. All implementers of `GenKillAnalysis` also implement
 ### Transfer Functions and Effects
 
 The dataflow framework in `rustc` allows each statement (and terminator) inside
-a basic block define its own transfer function. For brevity, these
+a basic block to define its own transfer function. For brevity, these
 individual transfer functions are known as "effects". Each effect is applied
 successively in dataflow order, and together they define the transfer function
 for the entire basic block. It's also possible to define an effect for

src/mir/drop-elaboration.md

@@ -111,7 +111,7 @@ a few optimizations:
 
 - Only paths that are the target of a `Drop` (or have the target as a prefix)
   need drop flags.
-- Some variables are known to initialized (or uninitialized) when they are
+- Some variables are known to be initialized (or uninitialized) when they are
   dropped. These do not need drop flags.
 - If a set of paths are only dropped or moved from via a shared prefix, those
   paths can share a single drop flag.

src/parallel-rustc.md

@@ -26,7 +26,7 @@ occurs in the `rustc_codegen_ssa::base` module.
 
 The underlying thread-safe data-structures used in the parallel compiler
 can be found in the `rustc_data_structures::sync` module. These data structures 
-are implemented diferently depending on whether `parallel-compiler` is true.
+are implemented differently depending on whether `parallel-compiler` is true.
 
 | data structure                   | parallel                                            | non-parallel |
 | -------------------------------- | --------------------------------------------------- | ------------ |

src/ty-fold.md

@@ -17,7 +17,7 @@ and
 
 For example, the `TypeFolder` trait has a method
 [`fold_ty`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/fold/trait.TypeFolder.html#method.fold_ty)
-that takes a type as input a type and returns a new type as a result. `TypeFoldable` invokes the
+that takes a type as input and returns a new type as a result. `TypeFoldable` invokes the
 `TypeFolder` `fold_foo` methods on itself, giving the `TypeFolder` access to its contents (the
 types, regions, etc that are contained within).