cargo check vs cargo build vs cargo clippy

Why this matters

These three commands form the daily Rust loop. cargo check type-checks without codegen — 5–10× faster than build, run it constantly while editing. cargo build produces actual binaries. cargo clippy runs an extra ~600 lints (pedantic, perf, correctness) on top of the type checker. The right rhythm: check on save, build before running, clippy before pushing. Don't skip clippy — it catches real bugs (stuff like if let Some(x) = y { } else { } that's actually a match).

Demo

cargo check, cargo build, and cargo test represent three distinct points on the compile-to-verify spectrum. cargo check runs type checking and borrow analysis without producing any binary — it's the fastest possible feedback loop during development. cargo build compiles to a real binary but skips test harness setup, while cargo test compiles a special test binary, runs your unit tests, and reports results. Using the right tool for the right moment cuts iteration time dramatically in large projects.

Try it yourself

1. Run all three on a real project (or the M1 wc-clone) and compare timings. check should be ~5× faster than build.
2. Wire cargo check to run on save in your editor (VS Code: rust-analyzer does this; Neovim: rust-analyzer LSP). Now you get errors instantly.
3. Run cargo clippy -- -W clippy::pedantic. This unlocks ~150 extra lints. Many will not apply, but reading them is educational.
4. Add cargo clippy --all-targets -- -D warnings to CI. -D warnings turns warnings into hard fails — this is how you keep them from accumulating.

Prompt your AI

Use these three in order. Each builds on the one before.

1. Basics & terminology

In one paragraph, explain the difference between `cargo check`, `cargo build`, and `cargo clippy`. When do I run each in a normal day?

2. Why it works (the mechanism)

What does `cargo check` skip that `cargo build` does — and why is that 5–10× faster? Cover MIR vs codegen vs linking.

3. Advanced — application & what's next

Some clippy lints (like `clippy::pedantic` group) generate false positives. What's a sane way to manage that for a team — workspace-level `clippy.toml`, `#[allow(clippy::xxx)]` on individual items, opt-in groups?

References

• Clippy Lints
• cargo check (cargo book)
• rust-analyzer