Add some details about `DefId` creation
This commit is contained in:
parent
e54c0c413f
commit
3166fb9d3e
|
|
@ -32,4 +32,16 @@ sanity checks in `src/librustc/hir/map/hir_id_validator.rs`:
|
||||||
4. If you are creating new nodes that didn't exist in the `AST`, you *must*
|
4. If you are creating new nodes that didn't exist in the `AST`, you *must*
|
||||||
create new ids for them. This is done by calling the `next_id` method,
|
create new ids for them. This is done by calling the `next_id` method,
|
||||||
which produces both a new `NodeId` as well as automatically lowering it
|
which produces both a new `NodeId` as well as automatically lowering it
|
||||||
for you so you also get the `HirId`.
|
for you so you also get the `HirId`.
|
||||||
|
|
||||||
|
If you are creating new `DefId`s, since each `DefId` needs to have a corresponding
|
||||||
|
`NodeId`, it is adviseable to add these `NodeId`s to the `AST` so you don't have
|
||||||
|
to generate new ones during lowering. This has the advantage of creating a
|
||||||
|
way to find the `DefId` of something via its `NodeId`. If lowering needs this
|
||||||
|
`DefId` in multiple places, you can't generate a new `NodeId` in all those places
|
||||||
|
because you'd also get a new `DefId` then. With a `NodeId` from the `AST` this is
|
||||||
|
not an issue.
|
||||||
|
|
||||||
|
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.
|
||||||
Loading…
Reference in New Issue