pub struct DepGraph { /* private fields */ }Expand description
A dependency graph over one program and the infrastructure its effects imply.
Implementations§
Source§impl DepGraph
impl DepGraph
pub fn len(&self) -> usize
pub fn is_empty(&self) -> bool
pub fn edge_count(&self) -> usize
pub fn nodes(&self) -> impl Iterator<Item = (NodeId, &GraphNode)>
pub fn node(&self, id: NodeId) -> &GraphNode
pub fn id(&self, name: &str) -> Option<NodeId>
Sourcepub fn dependencies(&self, id: NodeId) -> &[Edge]
pub fn dependencies(&self, id: NodeId) -> &[Edge]
What this node depends on.
Sourcepub fn dependents(&self, id: NodeId) -> &[Edge]
pub fn dependents(&self, id: NodeId) -> &[Edge]
What depends on this node — the direction that answers “what breaks if I change this”.
Sourcepub fn cycle_of(&self, id: NodeId) -> &[NodeId]
pub fn cycle_of(&self, id: NodeId) -> &[NodeId]
The strongly connected component this node is in. A single-element slice when the node is not in a cycle, which is the common case.
Sourcepub fn scc_index(&self, id: NodeId) -> u32
pub fn scc_index(&self, id: NodeId) -> u32
Component index, in topological order of the condensation.
Sourcepub fn cycles(&self) -> impl Iterator<Item = &[NodeId]>
pub fn cycles(&self) -> impl Iterator<Item = &[NodeId]>
The cycles: components with more than one member. Empty for an acyclic program; the todo example has exactly one, and it is the point of the architecture rather than a mistake.
Sourcepub fn topological(&self) -> &[NodeId]
pub fn topological(&self) -> &[NodeId]
Dependencies before dependents, with cycle members adjacent.
Sourcepub fn layers(&self) -> Vec<u32>
pub fn layers(&self) -> Vec<u32>
A layer per node: 0 for something that depends on nothing, otherwise one more than the deepest thing it depends on. Cycle members share a layer, because within a cycle there is no “deeper”.
This is the x-coordinate of a layered drawing — the shape Aspire’s graph view has, and the
reason it is computed here rather than in the browser: the condensation is already in
topological order, so one pass over it in that order gives every layer. O(V + E), against
the iterative force-directed relaxation a client-side layout would need.
Sourcepub fn impacted_by(&self, id: NodeId) -> Vec<NodeId>
pub fn impacted_by(&self, id: NodeId) -> Vec<NodeId>
Everything that transitively depends on id, including id. Breadth-first over the reverse
edges, so it costs the size of the affected region rather than the size of the program.
Sourcepub fn impact(&self, id: NodeId) -> Vec<(NodeId, u32)>
pub fn impact(&self, id: NodeId) -> Vec<(NodeId, u32)>
The same, with each node’s distance in hops from id, and nearest first.
The distance is what makes the answer usable rather than merely correct: “37 things depend on this” is a number, and “4 things depend on it directly, and the rest through them” is an answer. Breadth-first, so the first time a node is reached is by a shortest path.