Struct rustc_query_system::dep_graph::graph::DepNodeData

struct DepNodeData<K> {
    new: NewDepNodeData<K>,
    red: RedDepNodeData,
    light_green: LightGreenDepNodeData,
    unshared_edges: IndexVec<EdgeIndex, DepNodeIndex>,
    hybrid_indices: IndexVec<DepNodeIndex, CompressedHybridIndex>,
}

Data for nodes in the current graph, divided into different collections based on their presence in the previous graph, and if present, their color. We divide nodes this way because different types of nodes are able to share more or less data with the previous graph.

To enable more sharing, we distinguish between two kinds of green nodes. Light green nodes are nodes in the previous graph that have been marked green because we re-executed their queries and the results were the same as in the previous session. Dark green nodes are nodes in the previous graph that have been marked green because we were able to mark all of their dependencies green.

Both light and dark green nodes can share the dep node and fingerprint with the previous graph, but for light green nodes, we can’t be sure that the edges may be shared without comparing them against the previous edges, so we store them directly (an approach in which we compare edges with the previous edges to see if they can be shared was evaluated, but was not found to be very profitable).

For dark green nodes, we can share everything with the previous graph, which is why the HybridIndex::DarkGreen enum variant contains the index of the node in the previous graph, and why we don’t have a separate collection for dark green node data–the collection is the PreviousDepGraph itself.

(Note that for dark green nodes, the edges in the previous graph (SerializedDepNodeIndexs) must be converted to edges in the current graph (DepNodeIndexs). CurrentDepGraph contains prev_index_to_index, which can perform this conversion. It should always be possible, as by definition, a dark green node is one whose dependencies from the previous session have all been marked green–which means prev_index_to_index contains them.)

Node data is stored in parallel vectors to eliminate the padding between elements that would be needed to satisfy alignment requirements of the structure that would contain all of a node’s data. We could group tightly packing subsets of node data together and use fewer vectors, but for consistency’s sake, we use separate vectors for each piece of data.

Fields

new: NewDepNodeData<K>

Data for nodes not in previous graph.

red: RedDepNodeData

Data for nodes in previous graph that have been marked red.

light_green: LightGreenDepNodeData

Data for nodes in previous graph that have been marked light green.

unshared_edges: IndexVec<EdgeIndex, DepNodeIndex>

hybrid_indices: IndexVec<DepNodeIndex, CompressedHybridIndex>

Mapping from DepNodeIndex to an index into a collection above. Indicates which of the above collections contains a node’s data.

This collection is wasteful in time and space during incr-full builds, because for those, all nodes are new. However, the waste is relatively small, and the maintenance cost of avoiding using this for incr-full builds is somewhat high and prone to bugginess. It does not seem worth it at the time of this writing, but we may want to revisit the idea.