Problem
The [[patch.unused]] entries in Cargo.lock seem to end up in alphabetical order in the majority of cases, however cargo can sometimes write them to the lockfile out of order, leading to trivial lockfile changes.
It happens when running a cargo command that re-generates the lockfile (e.g. build, check) when starting with an empty global cache (in ~/.cargo) on a specific proprietary crate with proprietary patched crates from a private cargo registry. When running the same command another time, once cargo has already created its cache, the lockfile is reverted to its alphabetized state.
I'm unable to provide a way to reproduce this. This behavior happens consistently for this one specific crate, but hasn't occurred in the minimal examples I attempted to create.
Steps
No response
Possible Solution(s)
The list of patches could either be sorted prior to serialization, or could be stored in a collection that enforces order.
Notes
No response
Version
cargo 1.97.0 (c980f4866 2026-06-30)
release: 1.97.0
commit-hash: c980f4866141969fab6254a680546a277789d6f0
commit-date: 2026-06-30
host: x86_64-unknown-linux-gnu
libgit2: 1.9.2 (sys:0.20.4 vendored)
libcurl: 8.20.0-DEV (sys:0.4.88+curl-8.20.0 vendored ssl:OpenSSL/3.6.2)
ssl: OpenSSL 3.6.2 7 Apr 2026
os: Fedora 42.0.0 [64-bit]
Problem
The [[patch.unused]] entries in Cargo.lock seem to end up in alphabetical order in the majority of cases, however cargo can sometimes write them to the lockfile out of order, leading to trivial lockfile changes.
It happens when running a cargo command that re-generates the lockfile (e.g. build, check) when starting with an empty global cache (in ~/.cargo) on a specific proprietary crate with proprietary patched crates from a private cargo registry. When running the same command another time, once cargo has already created its cache, the lockfile is reverted to its alphabetized state.
I'm unable to provide a way to reproduce this. This behavior happens consistently for this one specific crate, but hasn't occurred in the minimal examples I attempted to create.
Steps
No response
Possible Solution(s)
The list of patches could either be sorted prior to serialization, or could be stored in a collection that enforces order.
Notes
No response
Version