diff options
| author | Niko Matsakis <niko@alum.mit.edu> | 2016-01-06 09:19:19 -0500 |
|---|---|---|
| committer | Niko Matsakis <niko@alum.mit.edu> | 2016-01-06 09:19:19 -0500 |
| commit | a9d7e366681c0157a557ff0083aa56fae9469fbf (patch) | |
| tree | 93cbc04f48446c8f6ccb54ffea834537cdf60cdd | |
| parent | 11c671b59ce0161be5835b5195729f0df5e024f5 (diff) | |
| download | rust-a9d7e366681c0157a557ff0083aa56fae9469fbf.tar.gz rust-a9d7e366681c0157a557ff0083aa56fae9469fbf.zip | |
Fix numerous typos, renamings, and minor nits raised by mw.
| -rw-r--r-- | src/librustc/dep_graph/README.md | 22 | ||||
| -rw-r--r-- | src/librustc/dep_graph/dep_tracking_map.rs | 16 | ||||
| -rw-r--r-- | src/librustc/dep_graph/edges.rs | 18 | ||||
| -rw-r--r-- | src/librustc/dep_graph/mod.rs | 2 | ||||
| -rw-r--r-- | src/librustc/dep_graph/thread.rs | 2 | ||||
| -rw-r--r-- | src/librustc/middle/ty/maps.rs | 4 |
6 files changed, 35 insertions, 29 deletions
diff --git a/src/librustc/dep_graph/README.md b/src/librustc/dep_graph/README.md index c607894c5e3..21742d9935d 100644 --- a/src/librustc/dep_graph/README.md +++ b/src/librustc/dep_graph/README.md @@ -123,7 +123,7 @@ However, you should rarely need to invoke those methods directly. Instead, the idea is to *encapsulate* shared state into some API that will invoke `read` and `write` automatically. The most common way to do this is to use a `DepTrackingMap`, described in the next section, -but any sort of abstraction brarier will do. In general, the strategy +but any sort of abstraction barrier will do. In general, the strategy is that getting access to information implicitly adds an appropriate `read`. So, for example, when you use the `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 the map). Each `DepTrackingMap` is parameterized by a special type `M` that -implements `DepTrackingMapId`; this trait defines the key and value +implements `DepTrackingMapConfig`; this trait defines the key and value types of the map, and also defines a fn for converting from the key to a `DepNode` label. You don't usually have to muck about with this by hand, 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 `DepNode::ItemSignature(K)` for a given key. Once that is done, you can just use the `DepTrackingMap` like any -other map. +other map: + +```rust +let mut map: DepTrackingMap<M> = DepTrackingMap::new(dep_graph); +map.insert(key, value); // registers dep_graph.write +map.get(key; // registers dep_graph.read +``` #### Memoization @@ -305,7 +311,7 @@ distinguish which fns used which fn sigs. There are various ways to write tests against the dependency graph. The simplest mechanism are the -`#[rustc_if_this_changed` and `#[rustc_then_this_would_need]` +`#[rustc_if_this_changed]` and `#[rustc_then_this_would_need]` annotations. These are used in compile-fail tests to test whether the expected set of paths exist in the dependency graph. As an example, see `src/test/compile-fail/dep-graph-caller-callee.rs`. @@ -354,7 +360,7 @@ source_filter // nodes originating from source_filter source_filter -> target_filter // nodes in between source_filter and target_filter ``` -`source_filter` and `target_filter` are a comma-separated list of strings. +`source_filter` and `target_filter` are a `&`-separated list of strings. A node is considered to match a filter if all of those strings appear in its label. So, for example: @@ -363,10 +369,10 @@ RUST_DEP_GRAPH_FILTER='-> TypeckItemBody' ``` would select the predecessors of all `TypeckItemBody` nodes. Usually though you -want the `TypeckItemBody` nod for some particular fn, so you might write: +want the `TypeckItemBody` node for some particular fn, so you might write: ``` -RUST_DEP_GRAPH_FILTER='-> TypeckItemBody,bar' +RUST_DEP_GRAPH_FILTER='-> TypeckItemBody & bar' ``` This 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 but you don't think you should have to. In that case, you might do: ``` -RUST_DEP_GRAPH_FILTER='Hir,foo -> TypeckItemBody,bar' +RUST_DEP_GRAPH_FILTER='Hir&foo -> TypeckItemBody & bar' ``` This will dump out all the nodes that lead from `Hir(foo)` to diff --git a/src/librustc/dep_graph/dep_tracking_map.rs b/src/librustc/dep_graph/dep_tracking_map.rs index 501c1aff320..c49e64f0f54 100644 --- a/src/librustc/dep_graph/dep_tracking_map.rs +++ b/src/librustc/dep_graph/dep_tracking_map.rs @@ -20,19 +20,19 @@ use super::{DepNode, DepGraph}; /// A DepTrackingMap offers a subset of the `Map` API and ensures that /// we make calls to `read` and `write` as appropriate. We key the /// maps with a unique type for brevity. -pub struct DepTrackingMap<M: DepTrackingMapId> { +pub struct DepTrackingMap<M: DepTrackingMapConfig> { phantom: PhantomData<M>, graph: DepGraph, map: FnvHashMap<M::Key, M::Value>, } -pub trait DepTrackingMapId { +pub trait DepTrackingMapConfig { type Key: Eq + Hash + Clone; type Value: Clone; fn to_dep_node(key: &Self::Key) -> DepNode; } -impl<M: DepTrackingMapId> DepTrackingMap<M> { +impl<M: DepTrackingMapConfig> DepTrackingMap<M> { pub fn new(graph: DepGraph) -> DepTrackingMap<M> { DepTrackingMap { phantom: PhantomData, @@ -71,7 +71,7 @@ impl<M: DepTrackingMapId> DepTrackingMap<M> { } } -impl<M: DepTrackingMapId> MemoizationMap for RefCell<DepTrackingMap<M>> { +impl<M: DepTrackingMapConfig> MemoizationMap for RefCell<DepTrackingMap<M>> { type Key = M::Key; type Value = M::Value; @@ -89,9 +89,9 @@ impl<M: DepTrackingMapId> MemoizationMap for RefCell<DepTrackingMap<M>> { /// **Important:* when `op` is invoked, the current task will be /// switched to `Map(key)`. Therefore, if `op` makes use of any /// HIR nodes or shared state accessed through its closure - /// environment, it must explicitly read that state. As an - /// example, see `type_scheme_of_item` in `collect`, which looks - /// something like this: + /// environment, it must explicitly register a read of that + /// state. As an example, see `type_scheme_of_item` in `collect`, + /// which looks something like this: /// /// ``` /// fn type_scheme_of_item(..., item: &hir::Item) -> ty::TypeScheme<'tcx> { @@ -126,7 +126,7 @@ impl<M: DepTrackingMapId> MemoizationMap for RefCell<DepTrackingMap<M>> { } } -impl<'k, M: DepTrackingMapId> Index<&'k M::Key> for DepTrackingMap<M> { +impl<'k, M: DepTrackingMapConfig> Index<&'k M::Key> for DepTrackingMap<M> { type Output = M::Value; #[inline] diff --git a/src/librustc/dep_graph/edges.rs b/src/librustc/dep_graph/edges.rs index 07b18944aa1..4b25285c476 100644 --- a/src/librustc/dep_graph/edges.rs +++ b/src/librustc/dep_graph/edges.rs @@ -12,7 +12,7 @@ use rustc_data_structures::fnv::{FnvHashMap, FnvHashSet}; use super::{DepGraphQuery, DepNode}; pub struct DepGraphEdges { - ids: Vec<DepNode>, + nodes: Vec<DepNode>, indices: FnvHashMap<DepNode, IdIndex>, edges: FnvHashSet<(IdIndex, IdIndex)>, open_nodes: Vec<OpenNode>, @@ -43,15 +43,15 @@ enum OpenNode { impl DepGraphEdges { pub fn new() -> DepGraphEdges { DepGraphEdges { - ids: vec![], + nodes: vec![], indices: FnvHashMap(), edges: FnvHashSet(), open_nodes: Vec::new() } } - fn id(&self, index: IdIndex) -> &DepNode { - &self.ids[index.index()] + fn id(&self, index: IdIndex) -> DepNode { + self.nodes[index.index()] } /// Creates a node for `id` in the graph. @@ -60,8 +60,8 @@ impl DepGraphEdges { return i; } - let index = IdIndex::new(self.ids.len()); - self.ids.push(id.clone()); + let index = IdIndex::new(self.nodes.len()); + self.nodes.push(id.clone()); self.indices.insert(id, index); index } @@ -83,7 +83,7 @@ impl DepGraphEdges { pub fn push_task(&mut self, key: DepNode) { let top_node = self.current_node(); - let new_node = self.make_node(key.clone()); + let new_node = self.make_node(key); self.open_nodes.push(OpenNode::Node(new_node)); // if we are in the midst of doing task T, then this new task @@ -155,8 +155,8 @@ impl DepGraphEdges { pub fn query(&self) -> DepGraphQuery { let edges: Vec<_> = self.edges.iter() - .map(|&(i, j)| (self.id(i).clone(), self.id(j).clone())) + .map(|&(i, j)| (self.id(i), self.id(j))) .collect(); - DepGraphQuery::new(&self.ids, &edges) + DepGraphQuery::new(&self.nodes, &edges) } } diff --git a/src/librustc/dep_graph/mod.rs b/src/librustc/dep_graph/mod.rs index c3d195811f2..9bf0a79115e 100644 --- a/src/librustc/dep_graph/mod.rs +++ b/src/librustc/dep_graph/mod.rs @@ -152,7 +152,7 @@ impl DepGraph { } } -pub use self::dep_tracking_map::{DepTrackingMap, DepTrackingMapId}; +pub use self::dep_tracking_map::{DepTrackingMap, DepTrackingMapConfig}; pub use self::query::DepGraphQuery; diff --git a/src/librustc/dep_graph/thread.rs b/src/librustc/dep_graph/thread.rs index f2a5b1c9ef9..dbc57605d71 100644 --- a/src/librustc/dep_graph/thread.rs +++ b/src/librustc/dep_graph/thread.rs @@ -48,7 +48,7 @@ pub struct DepGraphThreadData { // where to send buffer when full swap_out: Sender<Vec<DepMessage>>, - // where to receiver query results + // where to receive query results query_in: Receiver<DepGraphQuery>, } diff --git a/src/librustc/middle/ty/maps.rs b/src/librustc/middle/ty/maps.rs index e1fea5bba1d..924d420613c 100644 --- a/src/librustc/middle/ty/maps.rs +++ b/src/librustc/middle/ty/maps.rs @@ -8,7 +8,7 @@ // option. This file may not be copied, modified, or distributed // except according to those terms. -use dep_graph::{DepNode, DepTrackingMapId}; +use dep_graph::{DepNode, DepTrackingMapConfig}; use middle::def_id::DefId; use middle::ty; use std::marker::PhantomData; @@ -20,7 +20,7 @@ macro_rules! dep_map_ty { data: PhantomData<&'tcx ()> } - impl<'tcx> DepTrackingMapId for $ty_name<'tcx> { + impl<'tcx> DepTrackingMapConfig for $ty_name<'tcx> { type Key = $key; type Value = $value; fn to_dep_node(key: &$key) -> DepNode { DepNode::$node_name(*key) } |
