@@ -422,24 +422,3 @@ to see something like:
422422That first edge looks suspicious to you. So you set
423423` RUST_FORBID_DEP_GRAPH_EDGE ` to ` Hir&foo -> Collect&bar ` , re-run, and
424424then 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