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

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
+(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
+stone and may change over time. For the time being, we tend towards a
-a finer-grained division to help with compilation time, though as
+finer-grained division to help with compilation time, though as incremental
-incremental improves that may change.)
+compilation improves, that may change.)
 
 The dependency structure of these crates is roughly a diamond:
 

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
+    name things that are not nameable in normal Rust (e.g. `impl`s), and they
-    include extra information about the crate (such as its version number, since
+    also include extra information about the crate (such as its version number,
-    two versions of the same crate can co-exist).
+    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,
+The type inference is based on the standard Hindley-Milner (HM) type inference
-but extended in various way to accommodate subtyping, region inference,
+algorithm, but extended in various way to accommodate subtyping, region
-and higher-ranked types.
+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.