|
35 | 35 | //! "infer" some properties for each kind of `DepNode`: |
36 | 36 | //! |
37 | 37 | //! * Whether a `DepNode` of a given kind has any parameters at all. Some |
38 | | -//! `DepNode`s, like `Krate`, represent global concepts with only one value. |
| 38 | +//! `DepNode`s, like `AllLocalTraitImpls`, represent global concepts with only one value. |
39 | 39 | //! * Whether it is possible, in principle, to reconstruct a query key from a |
40 | 40 | //! given `DepNode`. Many `DepKind`s only require a single `DefId` parameter, |
41 | 41 | //! in which case it is possible to map the node's fingerprint back to the |
@@ -400,19 +400,6 @@ rustc_dep_node_append!([define_dep_nodes!][ <'tcx> |
400 | 400 | // We use this for most things when incr. comp. is turned off. |
401 | 401 | [] Null, |
402 | 402 |
|
403 | | - // Represents the `Krate` as a whole (the `hir::Krate` value) (as |
404 | | - // distinct from the krate module). This is basically a hash of |
405 | | - // the entire krate, so if you read from `Krate` (e.g., by calling |
406 | | - // `tcx.hir().krate()`), we will have to assume that any change |
407 | | - // means that you need to be recompiled. This is because the |
408 | | - // `Krate` value gives you access to all other items. To avoid |
409 | | - // this fate, do not call `tcx.hir().krate()`; instead, prefer |
410 | | - // wrappers like `tcx.visit_all_items_in_krate()`. If there is no |
411 | | - // suitable wrapper, you can use `tcx.dep_graph.ignore()` to gain |
412 | | - // access to the krate, but you must remember to add suitable |
413 | | - // edges yourself for the individual items that you read. |
414 | | - [eval_always] Krate, |
415 | | - |
416 | 403 | // Represents the body of a function or method. The def-id is that of the |
417 | 404 | // function/method. |
418 | 405 | [eval_always] HirBody(DefId), |
|
0 commit comments