One of the biggest issues that most people have with Rust are the long compile times. One of the reasons why compile times are so long is because many projects use quite a few dependencies from crates.io.
Your dependencies have dependencies of their own, and they in turn have dependencies as well, and so on. This results in really big graphs of crates that all have to be compiled by cargo.
Sometimes however, a crate actually doesn't use anything of some of its dependencies. Then those dependencies can be removed, resulting in faster builds for that crate.
But how do you detect them? Often they sit in Cargo.toml for a long time until someone discovers they are actually unused and removes them (example). This is where cargo-udeps comes in.
cargo-udeps is an automated tool to find dependencies that were specified in Cargo.toml but never used in the crate itself.
The name is a short form of "unused dependencies" but it is also a name play on the common ascii-ification of the greek µ letter, standing for "micro-deps".
Helping to mitigate the dependency bloat on crates.io is one of the goals of cargo-udeps.
I was inspired to do this project after I wanted to check which dependencies of nushell were unused. I ended up ripgrepping for dependency names one by one and removing them if they didn't appear anywhere in src and then checking whether this caused the build to fail. I then made a PR with the results. Then @eijebong suggested that I should create an automated tool for this.
I pondered over different approaches and for the MVP I ended up with a cargo plugin that reads save-analysis info (that was originally introduced for rls). The solution isn't perfect as it relies on an undocumented feature of rustc's save-analysis, but it actually runs the compiler so it is good at detecting actual usages. Alternative approaches that I want to explore later, like parsing of the crate's source code using syn, have this as a weakness.
After I finished the MVP I ran it on nushell again and I actually found two more crates that could be removed/disabled.
This 0.1.0 MVP release is meant to gauge interest in the ecosystem in such a tool. If there is demand, I want to invest more time into it and explore some of the more time-consuming approaches like using a syn parser. This would give faster performance, avoid having to compile the dependencies of the crate, and work on stable Rust instead of just nightly.
To install cargo-udeps, do cargo install cargo-udeps. Then you can run it on your project by doing cargo +nightly udeps.
@the8472 I've considered this idea and am on the fence with it. On one hand, it seems like the right thing to do. rustc is already quite lazy in its loading so it only loads external crates that it cares about (an earlier version of cargo-udeps even tried to exploit that but it ran into problems). You'd only have to add a callback to rustc to ask cargo to please compile that crate. Ideally then only the used crates would be compiled and cargo would automatically get information it can use to complain about unused crates. However, in large crate graphs, this might cause tons of memory usage as there could be long chains of rustc processes waiting on each other. There are further disadvantages like the compilation of the crate starting later so possibly there is less wall clock time spent in the build. idk whether it's worth it.