@@ -422,24 +422,3 @@ to see something like:
422
422
That first edge looks suspicious to you. So you set
423
423
` RUST_FORBID_DEP_GRAPH_EDGE ` to ` Hir&foo -> Collect&bar ` , re-run, and
424
424
then observe the backtrace. Voila, bug fixed!
425
-
426
- ### Inlining of HIR nodes
427
-
428
- For the time being, at least, we still sometimes "inline" HIR nodes
429
- from other crates into the current HIR map. This creates a weird
430
- scenario where the same logical item (let's call it ` X ` ) has two
431
- def-ids: the original def-id ` X ` and a new, inlined one ` X' ` . ` X' ` is
432
- in the current crate, but it's not like other HIR nodes: in
433
- particular, when we restart compilation, it will not be available to
434
- hash. Therefore, we do not want ` Hir(X') ` nodes appearing in our
435
- graph. Instead, we want a "read" of ` Hir(X') ` to be represented as a
436
- read of ` MetaData(X) ` , since the metadata for ` X ` is where the inlined
437
- representation originated in the first place.
438
-
439
- To achieve this, the HIR map will detect if the def-id originates in
440
- an inlined node and add a dependency to a suitable ` MetaData ` node
441
- instead. If you are reading a HIR node and are not sure if it may be
442
- inlined or not, you can use ` tcx.map.read(node_id) ` and it will detect
443
- whether the node is inlined or not and do the right thing. You can
444
- also use ` tcx.map.is_inlined_def_id() ` and
445
- ` tcx.map.is_inlined_node_id() ` to test.
0 commit comments