Skip to content

Commit d3b0eae

Browse files
insideoutclubmark-i-m
authored andcommitted
1 parent 946e11a commit d3b0eae

File tree

4 files changed

+5
-5
lines changed

4 files changed

+5
-5
lines changed

src/hir.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -81,7 +81,7 @@ sorts of identifiers in active use:
8181
about the crate (such as its version number, as two versions of
8282
the same crate can co-exist).
8383
- A [`DefId`] really consists of two parts, a `CrateNum` (which
84-
identifies the crate) and a `DefIndex` (which indixes into a list
84+
identifies the crate) and a `DefIndex` (which indexes into a list
8585
of items that is maintained per crate).
8686
- [`HirId`], which combines the index of a particular item with an
8787
offset within that item.

src/lowering.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -25,7 +25,7 @@ sanity checks in `src/librustc/hir/map/hir_id_validator.rs`:
2525
any `NodeId`s in the `HIR` are checked for existing `HirId`s)
2626
2. Lowering a `HirId` must be done in the scope of the *owning* item.
2727
This means you need to use `with_hir_id_owner` if you are creating parts
28-
of another item than the one being currently lowered. This happens for
28+
of an item other than the one being currently lowered. This happens for
2929
example during the lowering of existential `impl Trait`
3030
3. A `NodeId` that will be placed into a HIR structure must be lowered,
3131
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
4545

4646
Having the `NodeId` also allows the `DefCollector` to generate the `DefId`s
4747
instead of lowering having to do it on the fly. Centralizing the `DefId`
48-
generation in one place makes it easier to refactor and reason about.
48+
generation in one place makes it easier to refactor and reason about.

src/traits/canonical-queries.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -143,7 +143,7 @@ we did find. It consists of four parts:
143143

144144
Let's work through an example query to see what all the parts mean.
145145
Consider [the `Borrow` trait][borrow]. This trait has a number of
146-
impls; among them, there are these two (for clarify, I've written the
146+
impls; among them, there are these two (for clarity, I've written the
147147
`Sized` bounds explicitly):
148148

149149
[borrow]: https://doc.rust-lang.org/std/borrow/trait.Borrow.html

src/traits/canonicalization.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -29,7 +29,7 @@ they are repeated.
2929

3030
We use this to improve caching as well as to detect cycles and other
3131
things during trait resolution. Roughly speaking, the idea is that if
32-
two trait queries have the same canonicalize form, then they will get
32+
two trait queries have the same canonical form, then they will get
3333
the same answer. That answer will be expressed in terms of the
3434
canonical variables (`?0`, `?1`), which we can then map back to the
3535
original variables (`?T`, `?U`).

0 commit comments

Comments
 (0)