Minor grammar and syntax fixes

src/trait-caching.md

@@ -54,7 +54,7 @@ use is done by the method `pick_candidate_cache` in `select.rs`. At
 the moment, we use a very simple, conservative rule: if there are any
 where-clauses in scope, then we use the local cache.  We used to try
 and draw finer-grained distinctions, but that led to a serious of
-annoying and weird bugs like #22019 and #18290. This simple rule seems
+annoying and weird bugs like [#22019] and [#18290]. This simple rule seems
 to be pretty clearly safe and also still retains a very high hit rate
 (~95% when compiling rustc).
 
@@ -63,3 +63,5 @@ general, is this section still accurate at all?
 
 [`ParamEnv`]: ./param_env.html
 [`tcx`]: ./ty.html
+[#18290]: https://github.com/rust-lang/rust/issues/18290
+[#22019]: https://github.com/rust-lang/rust/issues/22019

src/traits-associated-types.md

@@ -20,6 +20,8 @@ that syntax is expanded during
 ["type collection"](./type-checking.html) into the explicit form,
 though that is something we may want to change in the future.)
 
+[intoiter-item]: https://doc.rust-lang.org/nightly/core/iter/trait.IntoIterator.html#associatedtype.Item
+
 <a name=normalize>
 
 In some cases, associated type projections can be **normalized** --
@@ -51,8 +53,8 @@ we saw above would be lowered to a program clause like so:
 
     forall<T> {
         Normalize(<Option<T> as IntoIterator>::Item -> T)
-    }    
-    
+    }
+
 (An aside: since we do not permit quantification over traits, this is
 really more like a family of predicates, one for each associated
 type.)
@@ -98,7 +100,7 @@ We now introduce the `ProjectionEq` predicate to bring those two cases
 together. The `ProjectionEq` predicate looks like so:
 
     ProjectionEq(<T as IntoIterator>::Item = U)
-    
+
 and we will see that it can be proven *either* via normalization or
 skolemization. As part of lowering an associated type declaration from
 some trait, we create two program clauses for `ProjectionEq`:
@@ -123,7 +125,7 @@ with unification. As described in the
 basically a procedure with a signature like this:
 
     Unify(A, B) = Result<(Subgoals, RegionConstraints), NoSolution>
-    
+
 In other words, we try to unify two things A and B. That procedure
 might just fail, in which case we get back `Err(NoSolution)`. This
 would happen, for example, if we tried to unify `u32` and `i32`.

src/type-inference.md

@@ -84,7 +84,7 @@ below in a separate section.
 
 The most basic operations you can perform in the type inferencer is
 **equality**, which forces two types `T` and `U` to be the same. The
-recommended way to add an equality constraint is using the `at`
+recommended way to add an equality constraint is to use the `at`
 method, roughly like so:
 
 ```rust