Auto merge of #7303 - alexcrichton:duplicate-patch, r=ehuss
Fixes around multiple `[patch]` per crate
This commit fixes a few bugs in handling of `[patch]` where multiple
version of the same crate name have been patched in. Two sub-issues were
discovered when investigating #7264:
* The first issue is that the source of the assertion, the logic in
`lock`, revealed a fundamental flaw in the logic. The `lock` function
serves the purpose of applying a lock file to a dependency candidate
and ensure that it stays within locked versions of dependencies, if
they're previously found. The logic here to handle `[patch]`, however,
happened a bit too late and was a bit too zealous to simply lock a
dependency by name instead of accounting for the version as well.
The updated logic is to move the locking of dependencies here to
during the normal iteration over the list of dependencies. Adjacent to
`matches_id` we check `matches_ignoring_source`. If the latter returns
`true` then we double-check that the previous dependency is still in
`[patch]`, and then we let it through. This means that patches with
multiple versions should be correctly handled where edges drawn with
`[patch]` are preserved.
* The second issue, after fixing this, was found where if the exact same
version was listed in `[patch]` multiple times then we would
continuously update the original source since one of the replacements
gets lost along the way. This commit adds a first-class warning
disallowing patches pointing to the exact same crate version, since we
don't have a way to prioritize amongst them anyway.
projects / cargo.git / commit