Build dependency DAG of workspace, at struct/enum/trait level

Given a cargo workspace, we can easily build a DAG of the crates just by reading the Cargo.toml file to see what depends on what.

I want something a bit more fine grained. I don't merely want to know that crate_foo depends on crate_bar.

I want to know that crate_foo::SomeStruct depends on crate_bar::SomeEnum.

Is there a tool for automating this ?

Context: I am looking at the output of cargo build --timing , refatoring crates, and it would really help to know the finegrained details of how one crate depends on another.

I've never heard of such a tool, but to do it properly you'd need to build something which pulls in rustc's internals as a dependency.

From there, it's quite possible (although monotonous and probably quite expensive) to query the type system to find all items referenced from a type definition, as well as anything mentioned in trait/inherent method signatures or their bodies.

Have you got any ideas for how you would display this information to the user? I imagine the output could be really spammy without some sort of "progressive disclosure" or filtering mechanism.

Rereading the question, I did bad job asking the question. Suppose we are trying to speed up / increase parallelism in build time. So we run cargo build --timings and get something like this:


08 | foo |-+
   +-----+ |
           | +--------+
23         +-| fruits |-+
             +--------+ |
                        | +---------------+
50                      +-| military jets |

Crate 23 (fruits) blocks on crate 08 (foo); and crate 50 (military jets) blocks on crate 23 (fruits).

So now we are curious -- why the $#(#&*@ does military jets depend on fruits ?

Right now, my approach is that I comment out the fruits dependency in military_jets/Cargo.toml, rerun rustc, and look at the errors to see what military_jets depends on fruits for.

A slightly better UI would be if for crate_A depends on crate_B in the output of cargo timings --build, we could click on crate_A and crate_B, and get a list of all the structs/enums/traits from crate_B that crate_A needs. (Along which structs/enum/traits from crate_A uses them).

That would be really helpful in figuring out which dependencies can be routed around (and build in parallel) and which dependencies we are stuck with.

Are free functions not relevant?

Free functions, constants, and macros all matter. However, I'd view this focus as nit picking minor details rather than helpfully moving towards a solution.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.