Fixed issues mentioned by @mark-i-m in review.

Author: Alexander Regueiro

src/SUMMARY.md

@@ -19,5 +19,5 @@
     - [MIR construction](./mir-construction.md)
     - [MIR borrowck](./mir-borrowck.md)
     - [MIR optimizations](./mir-optimizations.md)
-- [The `trans` crate: generating LLVM IR](./trans.md)
+- [Generating LLVM IR](./trans.md)
 - [Glossary](./glossary.md)

src/high-level-overview.md

@@ -12,10 +12,10 @@ Rustc consists of a number of crates, including `syntax`,
 many more. The source for each crate can be found in a directory
 like `src/libXXX`, where `XXX` is the crate name.
 
-(NB. The names and divisions of these crates are not set in
-stone and may change over time – for the time being, we tend towards
-a finer-grained division to help with compilation time, though as
-incremental improves that may change.)
+(N.B. The names and divisions of these crates are not set in
+stone and may change over time. For the time being, we tend towards a
+finer-grained division to help with compilation time, though as incremental
+compilation improves, that may change.)
 
 The dependency structure of these crates is roughly a diamond:
 
@@ -37,7 +37,7 @@ rustc_trans    rustc_borrowck   ...  rustc_metadata
                     /    \
                   /       \
            syntax_pos  syntax_ext
-```                    
+```
 
 The `rustc_driver` crate, at the top of this lattice, is effectively
 the "main" function for the rust compiler. It doesn't have much "real
@@ -127,7 +127,7 @@ take:
 4. **Lowering to MIR and post-processing**
     - Once type-checking is done, we can lower the HIR into MIR ("middle IR"), which
       is a **very** desugared version of Rust, well suited to the borrowck but also
-      certain high-level optimizations. 
+      certain high-level optimizations.
 5. **Translation to LLVM and LLVM optimizations**
     - From MIR, we can produce LLVM IR.
     - LLVM then runs its various optimizations, which produces a number of `.o` files

src/hir.md

@@ -59,9 +59,9 @@ sorts of identifiers in active use:
 - `DefId` – primarily names "definitions" or top-level items.
   - You can think of a `DefId` as shorthand for a very explicit and complete
     path, like `std::collections::HashMap`. However, these paths are able to
-    name things that are not nameable in normal Rust (e.g. impls), and they also
-    include extra information about the crate (such as its version number, since
-    two versions of the same crate can co-exist).
+    name things that are not nameable in normal Rust (e.g. `impl`s), and they
+    also include extra information about the crate (such as its version number,
+    since two versions of the same crate can co-exist).
   - A `DefId` really consists of two parts, a `CrateNum` (which identifies the
     crate) and a `DefIndex` (which indexes into a list of items that is
     maintained per crate).

src/trans.md

@@ -1 +1 @@
-# The `trans` crate: generating LLVM IR
+# Generating LLVM IR

src/type-inference.md

@@ -1,8 +1,8 @@
 # Type inference
 
-The type inference is based on the standard Hindley–Milner (HM) system,
-but extended in various way to accommodate subtyping, region inference,
-and higher-ranked types.
+The type inference is based on the standard Hindley-Milner (HM) type inference
+algorithm, but extended in various way to accommodate subtyping, region
+inference, and higher-ranked types.
 
 ## A note on terminology
 
@@ -12,7 +12,7 @@ existential variables.
 We use the terms "region" and "lifetime" interchangeably. Both refer to
 the `'a` in `&'a T`.
 
-The term "bound region" refers to a region bound in a function
+The term "bound region" refers to a region that is a bound in a function
 signature, such as the `'a` in `for<'a> fn(&'a u32)`. A region is
 "free" if it is not bound.