address nits

src/borrow_check.md

@@ -38,10 +38,10 @@ the [`mir_borrowck`] query.
 [b_c]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/index.html
 [`mir_borrowck`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/fn.mir_borrowck.html
 
-- We first create a **local copy** C of the MIR. In the coming steps,
+- We first create a **local copy** of the MIR. In the coming steps,
   we will modify this copy in place to modify the types and things to
   include references to the new regions that we are computing.
-- We then invoke [`replace_regions_in_mir`] to modify this copy C.
+- We then invoke [`replace_regions_in_mir`] to modify our local MIR.
   Among other things, this function will replace all of the [regions](./appendix/glossary.html) in
   the MIR with fresh [inference variables](./appendix/glossary.html).
 - Next, we perform a number of
@@ -51,7 +51,7 @@ the [`mir_borrowck`] query.
   the purpose of this type check is to determine all of the constraints between
   different regions.
 - Next, we do [region inference](borrow_check/region_inference.html), which computes
-  the values of each region -- basically, points in the control-flow graph.
+  the values of each region — basically, points in the control-flow graph.
 - At this point, we can compute the "borrows in scope" at each point.
 - Finally, we do a second walk over the MIR, looking at the actions it
   does and reporting errors. For example, if we see a statement like

src/borrow_check/moves_and_initialization.md

@@ -11,9 +11,9 @@ value -- and moves -- transfering ownership to another place -- might
 seem like distinct topics. Indeed, our borrow checker error messages
 often talk about them differently. But **within the borrow checker**,
 they are not nearly as separate. Roughly speaking, the borrow checker
-tracks the set of "initialized places" at any point in time. Assigning
-to a previously uninitialized local variable adds it to that set;
-moving from a local variable removes it from that set.
+tracks the set of "initialized places" at any point in the source
+code. Assigning to a previously uninitialized local variable adds it
+to that set; moving from a local variable removes it from that set.
 
 Consider this example:
 
@@ -36,8 +36,8 @@ fn foo() {
 ```
 
 Here you can see that `a` starts off as uninitialized; once it is
-assigned, it becomes initialized. But when `drop(a)` is called, it
-becomes uninitialized again.
+assigned, it becomes initialized. But when `drop(a)` is called, that
+moves `a` into the call, and hence it becomes uninitialized again.
 
 ## Subsections
 
@@ -47,4 +47,4 @@ subsections:
 - [Move paths](./moves_and_initialization/move_paths.html the
   *move path* concept that we use to track which local variables (or parts of
   local variables, in some cases) are initialized.
-- *Rest not yet written* =)
+- TODO *Rest not yet written* =)

src/borrow_check/moves_and_initialization/move_paths.md

@@ -1,7 +1,8 @@
 # Move paths
 
 In reality, it's not enough to track initialization at the granularity
-of local variables. Sometimes we need to track, e.g., individual fields:
+of local variables. Rust also allows us to do moves and initialization
+at the field granularity:
 
 ```rust
 fn foo() {
@@ -63,9 +64,9 @@ later section.
 
 ### Illegal move paths
 
-We don't actually move-paths for **every** [`Place`] that gets used.
-In particular, if it is illegal to move from a [`Place`], then there
-is no need for a [`MovePathIndex`]. Some examples:
+We don't actually create a move-path for **every** [`Place`] that gets
+used.  In particular, if it is illegal to move from a [`Place`], then
+there is no need for a [`MovePathIndex`]. Some examples:
 
 - You cannot move from a static variable, so we do not create a [`MovePathIndex`]
   for static variables.
@@ -115,11 +116,12 @@ they are also structured into a tree. So for example if you have the
 [`MovePathIndex`] for `a.b.c`, you can go to its parent move-path
 `a.b`. You can also iterate over all children paths: so, from `a.b`,
 you might iterate to find the path `a.b.c` (here you are iterating
-just over the paths that the user **actually referenced**, not all
-**possible** paths the user could have done). These references are
-used for example in the [`has_any_child_of`] function, which checks
-whether the dataflow results contain a value for the given move-path
-(e.g., `a.b`) or any child of that move-path (e.g., `a.b.c`).
+just over the paths that are **actually referenced** in the source,
+not all **possible** paths that could have been referenced). These
+references are used for example in the [`has_any_child_of`] function,
+which checks whether the dataflow results contain a value for the
+given move-path (e.g., `a.b`) or any child of that move-path (e.g.,
+`a.b.c`).
 
 [`Place`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/enum.Place.html
 [`has_any_child_of`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/at_location/struct.FlowAtLocation.html#method.has_any_child_of

src/borrow_check/type_check.md

@@ -7,5 +7,4 @@ kind you might find in any other language. In the process of doing
 this type-check, we also uncover the region constraints that apply to
 the program.
 
-
-
+TODO -- elaborate further? Maybe? :)