Typo nits #181 (#205)

4 files changed, 5 insertions, 5 deletions

diff --git a/src/doc/rustc-dev-guide/src/hir.md b/src/doc/rustc-dev-guide/src/hir.md
index a5e99e8b3b5..e6bca7f37d0 100644
--- a/src/doc/rustc-dev-guide/src/hir.md
+++ b/src/doc/rustc-dev-guide/src/hir.md
@@ -81,7 +81,7 @@ sorts of identifiers in active use:
     about the crate (such as its version number, as 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 indixes into a list
+    identifies the crate) and a `DefIndex` (which indexes into a list
     of items that is maintained per crate).
 - [`HirId`], which combines the index of a particular item with an
   offset within that item.
diff --git a/src/doc/rustc-dev-guide/src/lowering.md b/src/doc/rustc-dev-guide/src/lowering.md
index 2504ed4911f..c3a1a96ccf2 100644
--- a/src/doc/rustc-dev-guide/src/lowering.md
+++ b/src/doc/rustc-dev-guide/src/lowering.md
@@ -25,7 +25,7 @@ sanity checks in `src/librustc/hir/map/hir_id_validator.rs`:
   any `NodeId`s in the `HIR` are checked for existing `HirId`s)
 2. Lowering a `HirId` must be done in the scope of the *owning* item.
   This means you need to use `with_hir_id_owner` if you are creating parts
-  of another item than the one being currently lowered. This happens for
+  of an item other than the one being currently lowered. This happens for
   example during the lowering of existential `impl Trait`
 3. A `NodeId` that will be placed into a HIR structure must be lowered,
   even if its `HirId` is unused. Calling
@@ -45,4 +45,4 @@ generate a new `NodeId` in all those places because you'd also get a new
 
 Having the `NodeId` also allows the `DefCollector` to generate the `DefId`s
 instead of lowering having to do it on the fly. Centralizing the `DefId`
-generation in one place makes it easier to refactor and reason about.
\ No newline at end of file
+generation in one place makes it easier to refactor and reason about.
diff --git a/src/doc/rustc-dev-guide/src/traits/canonical-queries.md b/src/doc/rustc-dev-guide/src/traits/canonical-queries.md
index 876c5d8a6d7..cbf7d880d0d 100644
--- a/src/doc/rustc-dev-guide/src/traits/canonical-queries.md
+++ b/src/doc/rustc-dev-guide/src/traits/canonical-queries.md
@@ -143,7 +143,7 @@ we did find. It consists of four parts:
 
 Let's work through an example query to see what all the parts mean.
 Consider [the `Borrow` trait][borrow]. This trait has a number of
-impls; among them, there are these two (for clarify, I've written the
+impls; among them, there are these two (for clarity, I've written the
 `Sized` bounds explicitly):
 
 [borrow]: https://doc.rust-lang.org/std/borrow/trait.Borrow.html
diff --git a/src/doc/rustc-dev-guide/src/traits/canonicalization.md b/src/doc/rustc-dev-guide/src/traits/canonicalization.md
index df0c4a2b936..62c4d9f7483 100644
--- a/src/doc/rustc-dev-guide/src/traits/canonicalization.md
+++ b/src/doc/rustc-dev-guide/src/traits/canonicalization.md
@@ -29,7 +29,7 @@ they are repeated.
 
 We use this to improve caching as well as to detect cycles and other
 things during trait resolution. Roughly speaking, the idea is that if
-two trait queries have the same canonicalize form, then they will get
+two trait queries have the same canonical form, then they will get
 the same answer. That answer will be expressed in terms of the
 canonical variables (`?0`, `?1`), which we can then map back to the
 original variables (`?T`, `?U`).