|
| 1 | +# Identifiers in the Compiler |
| 2 | + |
| 3 | +If you have read the few previous chapters, you now know that the `rustc` uses |
| 4 | +many different intermediate representations to perform different kinds of analysis. |
| 5 | +However, like in every data structure, you need a way to traverse the structure |
| 6 | +and refer to other elements. In this chapter, you will find information on the |
| 7 | +different identifiers `rustc` uses for each intermediate representation. |
| 8 | + |
| 9 | +## In the AST |
| 10 | + |
| 11 | +A [`NodeId`] is an identifier number that uniquely identifies an AST node within |
| 12 | +a crate. Every node in the AST has its own [`NodeId`], including top-level items |
| 13 | +such as structs, but also individual statements and expressions. |
| 14 | + |
| 15 | +However, because they are absolute within in a crate, adding or removing a single |
| 16 | +node in the AST causes all the subsequent [`NodeId`]s to change. This renders |
| 17 | +[`NodeId`]s pretty much useless for incremental compilation, where you want as |
| 18 | +few things as possible to change. |
| 19 | + |
| 20 | +[`NodeId`]s are used in all the `rustc` bits that operate directly on the AST, |
| 21 | +like macro expansion and name resolution. |
| 22 | + |
| 23 | +[`NodeId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/node_id/struct.NodeId.html |
| 24 | + |
| 25 | +## In the HIR |
| 26 | + |
| 27 | +The HIR uses a bunch of different identifiers that coexist and serve different purposes. |
| 28 | + |
| 29 | +- A [`DefId`], as the name suggests, identifies a particular definition, or top-level |
| 30 | + item, in a given grate. It is composed of two parts: a [`CrateNum`] which identifies |
| 31 | + the crate the definition comes from, and a [`DefIndex`] which identifies the definition |
| 32 | + within the crate. Unlike [`NodeId`]s, there isn't a [`DefId`] for every expression, which |
| 33 | + makes them more stable across compilations. |
| 34 | +- A [`LocalDefId`] is basically a [`DefId`] that is known to come from the current crate. |
| 35 | + This allows us to drop the [`CrateNum`] part, and use the type system to ensure that |
| 36 | + only local definitions are passed to functions that expect a local definition. |
| 37 | +- A [`HirId`] uniquely identifies a node in the HIR of the current crate. It is composed |
| 38 | + of two parts: an `owner` and a `local_id` that is unique within the `owner`. This |
| 39 | + combination makes for more stable values which are helpful for incremental compilation. |
| 40 | + Unlike [`DefId`]s, a [`HirId`] can refer to [fine-grained entities][Node] like expressions, |
| 41 | + but stays local to the current crate. |
| 42 | +- A [`BodyId`] identifies a HIR [`Body`] in the current crate. It is currenty only |
| 43 | + a wrapper around a [`HirId`]. For more info about HIR bodies, please refer to the |
| 44 | + [HIR chapter][hir-bodies]. |
| 45 | + |
| 46 | +These identifiers can be converted into one another through the [HIR map][map]. |
| 47 | +See the [HIR chapter][hir-map] for more detailed information. |
| 48 | + |
| 49 | +[`DefId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/def_id/struct.DefId.html |
| 50 | +[`LocalDefId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/def_id/struct.LocalDefId.html |
| 51 | +[`HirId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir_id/struct.HirId.html |
| 52 | +[`BodyId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.BodyId.html |
| 53 | +[Node]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir/enum.Node.html |
| 54 | +[hir-map]: ./hir.md#the-hir-map |
| 55 | +[hir-bodies]: ./hir.md#hir-bodies |
| 56 | +[map]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/struct.Map.html |
| 57 | + |
| 58 | +## In the MIR |
| 59 | + |
| 60 | +**TODO** |
0 commit comments