@@ -123,7 +123,7 @@ However, you should rarely need to invoke those methods directly.
123123Instead, the idea is to * encapsulate* shared state into some API that
124124will invoke ` read ` and ` write ` automatically. The most common way to
125125do this is to use a ` DepTrackingMap ` , described in the next section,
126- but any sort of abstraction brarier will do. In general, the strategy
126+ but any sort of abstraction barrier will do. In general, the strategy
127127is that getting access to information implicitly adds an appropriate
128128` read ` . So, for example, when you use the
129129` dep_graph::visit_all_items_in_krate ` helper method, it will visit
@@ -197,7 +197,7 @@ from/to the node `DepNode::Variant(K)` (for some variant specific to
197197the map).
198198
199199Each ` DepTrackingMap ` is parameterized by a special type ` M ` that
200- implements ` DepTrackingMapId ` ; this trait defines the key and value
200+ implements ` DepTrackingMapConfig ` ; this trait defines the key and value
201201types of the map, and also defines a fn for converting from the key to
202202a ` DepNode ` label. You don't usually have to muck about with this by
203203hand, there is a macro for creating it. You can see the complete set
@@ -221,7 +221,13 @@ of the map will be a `DefId` and value will be
221221` DepNode::ItemSignature(K) ` for a given key.
222222
223223Once that is done, you can just use the ` DepTrackingMap ` like any
224- other map.
224+ other map:
225+
226+ ``` rust
227+ let mut map : DepTrackingMap <M > = DepTrackingMap :: new (dep_graph );
228+ map . insert (key , value ); // registers dep_graph.write
229+ map . get (key ; // registers dep_graph.read
230+ ```
225231
226232#### Memoization
227233
@@ -305,7 +311,7 @@ distinguish which fns used which fn sigs.
305311
306312There are various ways to write tests against the dependency graph.
307313The simplest mechanism are the
308- ` #[rustc_if_this_changed ` and ` #[rustc_then_this_would_need] `
314+ ` #[rustc_if_this_changed] ` and ` #[rustc_then_this_would_need] `
309315annotations. These are used in compile-fail tests to test whether the
310316expected set of paths exist in the dependency graph. As an example,
311317see ` src/test/compile-fail/dep-graph-caller-callee.rs ` .
@@ -354,7 +360,7 @@ source_filter // nodes originating from source_filter
354360source_filter -> target_filter // nodes in between source_filter and target_filter
355361```
356362
357- ` source_filter ` and ` target_filter ` are a comma -separated list of strings.
363+ ` source_filter ` and ` target_filter ` are a ` & ` -separated list of strings.
358364A node is considered to match a filter if all of those strings appear in its
359365label. So, for example:
360366
@@ -363,10 +369,10 @@ RUST_DEP_GRAPH_FILTER='-> TypeckItemBody'
363369```
364370
365371would select the predecessors of all ` TypeckItemBody ` nodes. Usually though you
366- want the ` TypeckItemBody ` nod for some particular fn, so you might write:
372+ want the ` TypeckItemBody ` node for some particular fn, so you might write:
367373
368374```
369- RUST_DEP_GRAPH_FILTER='-> TypeckItemBody, bar'
375+ RUST_DEP_GRAPH_FILTER='-> TypeckItemBody & bar'
370376```
371377
372378This will select only the ` TypeckItemBody ` nodes for fns with ` bar ` in their name.
@@ -375,7 +381,7 @@ Perhaps you are finding that when you change `foo` you need to re-type-check `ba
375381but you don't think you should have to. In that case, you might do:
376382
377383```
378- RUST_DEP_GRAPH_FILTER='Hir, foo -> TypeckItemBody, bar'
384+ RUST_DEP_GRAPH_FILTER='Hir& foo -> TypeckItemBody & bar'
379385```
380386
381387This will dump out all the nodes that lead from ` Hir(foo) ` to
0 commit comments