Features and bugs that might need a bump of Cargo.lock version

[weihanglo]

Problem

There are several issues might need a bump of Cargo.lock version when fixing them. Here is a non-exhaustive list I kept in my notebook for a while.

• The lockfile is ambiguous when two packages are actually the same rev (due to different branch names or using short rev)
  • Cargo should reference git dependencies by commit hash instead of url #7497
  • The dependency resolution is confused when using git dependency and there's a lockfile #11490
  • Multiple git dependencies with different refs confuses cargo #10256 (comment)
• Query string is not properly serialized in SourceId, especially for branch names (use git check-ref-format --branch <name> to check)
  • SourceId serialization is ambiguous due to lack of escaping #11085
  • cargo updates git repository on any action when using a tag #11792
  • Pull request: fix: encode URL params correctly for SourceId in Cargo.lock #12280
• Path dependencies are ambiguous when theirs names and versions collide
  • Unavoidable Cargo.lock package collision occurs if path dependencies share same name and version #10353
  • Alex's reply: This is an intended limitation of the Cargo.lock format at this time, path dependencies must all have unique names.
  • Cargo fails to compile a crate if it's included multiple times at different paths #8639 is simlilar but they said rustc can handle that.
• Sparse registry migration. Use sparse+ in Cargo.lock for alternative registries.
  • sparse registry: determine UX and URL handling #10964
  • If we want this. Do we need to have a new lockfile version, as old cargos are not able to understand sparse+ protocol.
• Remove optional dependencies in Cargo.lock
  • Disabled optional weak dependencies end up in Cargo.lock #10801
• Cargo.lock contains package's own version. Might be unnecessarily.
  • Cargo.lock contains project's own version, unnecessarily #5979
• Some unused patches are not recorded correctly in the lockfile.
  • Unused path dependency patches don't emit warning or show up in lock file on update #12464

Proposed Solution

We could have put corresponding fixes and the lock version bump behind an unstable feature. When we collect enough changes, bump it altogether. Keep in mind that ship too many large-scale changes in a bump might also be a bit risky.

Notes

No response

[weihanglo]

Things TODO when making lockfile v4 the default version

• Wait for the stabilzation of v4 hitting stable or stable+n versions.
• Search next-lockfile-bump and change to GitReference::pretty_ref(true) from false.