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
|
about the crate (such as its version number, as two versions of
|
||||||
the same crate can co-exist).
|
the same crate can co-exist).
|
||||||
- A [`DefId`] really consists of two parts, a `CrateNum` (which
|
- 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).
|
of items that is maintained per crate).
|
||||||
- [`HirId`], which combines the index of a particular item with an
|
- [`HirId`], which combines the index of a particular item with an
|
||||||
offset within that item.
|
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)
|
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.
|
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
|
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`
|
example during the lowering of existential `impl Trait`
|
||||||
3. A `NodeId` that will be placed into a HIR structure must be lowered,
|
3. A `NodeId` that will be placed into a HIR structure must be lowered,
|
||||||
even if its `HirId` is unused. Calling
|
even if its `HirId` is unused. Calling
|
||||||
|
|
|
||||||
|
|
@ -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.
|
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
|
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):
|
`Sized` bounds explicitly):
|
||||||
|
|
||||||
[borrow]: https://doc.rust-lang.org/std/borrow/trait.Borrow.html
|
[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
|
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
|
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
|
the same answer. That answer will be expressed in terms of the
|
||||||
canonical variables (`?0`, `?1`), which we can then map back to the
|
canonical variables (`?0`, `?1`), which we can then map back to the
|
||||||
original variables (`?T`, `?U`).
|
original variables (`?T`, `?U`).
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue