Module tree 

Traversal — materialize the spanning containment tree from a root document.

This is the discovery walk the whole crate exists for: start at a document, follow the spanning relation’s links declared in each document, and the workspace structure unfolds. The walk is resilient by design — a missing or unparseable target becomes a marked node, not an error — because a traversal that dies on the first broken link cannot power tree, check, or any editor view of an imperfect (i.e. real) workspace.

Why this is a second walker, not a view over census. The census is a flat BFS over a global visited set: once a path is reached it is never redescended, and a spanning edge back into it is a finding (a second parent breaking the single-parent tree). This walk is a DFS over a per-branch trail: revisiting a node from another branch is fine (each branch materializes its own subtree — that is what makes tree a tree rather than a DAG rendered flat), and only a back-edge to an ancestor on the current path is a cycle. Forcing one skeleton to serve both would mean threading two different revisit policies through a single traversal, which is more machinery than two short, separately-readable walks. They stay side by side in graph because they walk the same edges from the same Graph, not because they share a shape.

Structs

Node

One node of the materialized spanning tree.

TreeOptions

Options controlling how Graph::tree_with materializes a spanning target that does not resolve on disk.

Enums

NodeKind

Why a node appears in the tree the way it does.