Rust Doctor
Open navigation
← Back to blog

Introducing rust-doctor

A health scan for Rust workspaces: what it checks, why it refuses to guess, and how to run it.

Arthur Jean

Why rust-doctor?

The compiler catches memory safety and types. It says nothing about a panic waiting to happen in a library, a blocking call held across an await, a dependency that only resolves on your machine, or TLS verification switched off in a helper nobody reads anymore.

Clippy sees a lot of that, and it sees hundreds of other things at the same time. Pointed at an existing codebase it produces a wall of output nobody triages, which is the same as producing nothing.

rust-doctor scans a workspace with 62 rules, scores it out of 100, and ends by naming the three worth fixing first.

Run it

npx -y rust-doctor@latest .

Everything runs on your machine. No network, no upload, no telemetry.

What is behind the 62

37 curated Clippy lints, and 25 native detectors that read what Clippy does not: your manifests and .cargo/config.toml, families of near-duplicate code, what git actually tracks, and the source text itself.

Every rule was admitted on measurement, not on intuition. Each one is scored against ten public repositories pinned by commit, and publishes the rate at which it was wrong on healthy code. That rate decides what the report tells you to fix first: what a rule costs, discounted by how often it is noise.

It never reduces what a rule costs the score. What a rule costs is what it reported.

What it refuses to do

It refuses to score a scan that did not finish. If a pass fails, the report says so at that stage and drops the score's authoritative flag, rather than handing you a number that quietly means less than the one next to it.

It refuses to invent a suppression syntax of its own, so an exception stays readable to every other tool.

And it asks nothing before scanning. You answer questions after seeing findings, not before.