Cargo.toml with no Cargo.lock
Part of Dependencies & Hygiene, which counts for 10% of the overall score. When this check fires it deducts 8 points from that category, once per scan, no matter how many places it turns up.
What it detects
A Cargo.toml exists with no Cargo.lock in the same directory, so cargo build can resolve different crate versions between environments.
Why it matters
A Cargo.toml with no Cargo.lock means cargo build resolves crate versions fresh within whatever ranges Cargo.toml allows, so different builds can pull different dependency versions. For applications and binaries this defeats reproducible builds; Cargo.lock is only conventionally left out of version control for pure libraries meant to be consumed by other crates, and even then a lock file should exist during development.
How to fix it
Run cargo build or cargo generate-lockfile once and commit the resulting Cargo.lock (unless this crate is a published library intentionally excluding the lockfile from its published/consumed form -- in that case make sure a lock still exists in CI). Use cargo build --locked in CI so an out-of-date lock fails the build instead of silently re-resolving.
The paid report includes a ready-to-paste prompt for your AI coding agent for every check it finds, pointed at the exact findings from your scan. See pricing
Does your repo trip this check?
Paste a GitHub URL or drop a project folder. Scans run in your browser and take seconds.
Scan your repo