This commit is contained in:
David Sanders 2018-09-28 18:47:52 -07:00 committed by Who? Me?!
parent b9d3a71115
commit 8f85624f2b
4 changed files with 5 additions and 5 deletions

View File

@ -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.

View File

@ -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.
generation in one place makes it easier to refactor and reason about.

View File

@ -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

View File

@ -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`).