parent
b9d3a71115
commit
8f85624f2b
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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`).
|
||||
|
|
|
|||
Loading…
Reference in New Issue