Skip to content

Commit 80b5f98

Browse files
committed
remove outdated text
1 parent 1c0c2af commit 80b5f98

File tree

1 file changed

+0
-21
lines changed

1 file changed

+0
-21
lines changed

src/librustc/dep_graph/README.md

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

Comments
 (0)