-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixes around multiple [patch]
per crate
#7303
Conversation
r? @ehuss (rust_highfive has picked a reviewer for you, use r? to override) |
☔ The latest upstream changes (presumably #7263) made this pull request unmergeable. Please resolve the merge conflicts. |
One more thing, can you add some documentation on |
a2f53db
to
87e8024
Compare
Ok I think that should cover everything, thanks for taking a look! Definitely agreed that we should have internal documentation of how lock files work, as it's pretty subtle in how it actually ends up working! |
src/cargo/core/registry.rs
Outdated
@@ -79,7 +80,28 @@ pub struct PackageRegistry<'cfg> { | |||
patches_available: HashMap<Url, Vec<PackageId>>, | |||
} | |||
|
|||
type LockedMap = HashMap<SourceId, HashMap<String, Vec<(PackageId, Vec<PackageId>)>>>; | |||
/// A map of all "locked packages" which is filled in when parsing a lock file | |||
/// and is used to guide dependency resolution by altering summaires as they're |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/// and is used to guide dependency resolution by altering summaires as they're | |
/// and is used to guide dependency resolution by altering summaries as they're |
Thanks, r=me with typo fix.
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 rust-lang#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. Closes rust-lang#7264
87e8024
to
803bf32
Compare
@bors: r=ehuss |
📌 Commit 803bf32 has been approved by |
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. Closes #7264
☀️ Test successful - checks-azure |
Update cargo, books ## cargo 8 commits in 22f7dd0495cd72ce2082d318d5a9b4dccb9c5b8c..fe0e5a48b75da2b405c8ce1ba2674e174ae11d5d 2019-08-27 16:10:51 +0000 to 2019-09-04 00:51:27 +0000 - Rename `--all` to `--workspace` (rust-lang/cargo#7241) - Basic standard library support. (rust-lang/cargo#7216) - Allow using 'config.toml' instead of just 'config' files. (rust-lang/cargo#7295) - Retry on SSL Connect Error. (rust-lang/cargo#7318) - minimal-copy `deserialize` for `InternedString` (rust-lang/cargo#7310) - Fix typo in cargo vendor examples (rust-lang/cargo#7320) - Fixes around multiple `[patch]` per crate (rust-lang/cargo#7303) - Improve error messages on mkdir failure (rust-lang/cargo#7306) ## reference 7 commits in d191a0c..090c015 2019-08-15 08:42:23 +0200 to 2019-09-03 13:59:28 -0700 - Fix rust-lang/reference#664: Review Oxford comma usage. (rust-lang/reference#668) - Fix some links. (rust-lang/reference#667) - Remove trait object warning. (rust-lang/reference#666) - Specify pattern types in `let` statements and `for` expressions (rust-lang/reference#663) - Fix loop expression link. (rust-lang/reference#662) - async-await initial reference material (rust-lang/reference#635) - Correct errors in the reference of extern functions definitions and declarations (rust-lang/reference#652) ## rust-by-example 1 commits in 580839d90aacd537f0293697096fa8355bc4e673..e76be6b2dc84c6a992e186157efe29d625e29b94 2019-08-17 23:17:50 -0300 to 2019-09-03 07:42:26 -0300 - Change link to russian translation repository (rust-lang/rust-by-example#1245) ## embedded-book 1 commits in 432ca26686c11d396eed6a59499f93ce1bf2433c..5ca585c4a7552efb546e7681c3de0712f4ae4fdc 2019-08-09 23:20:22 +0000 to 2019-08-27 13:39:14 +0000 - Fixup book CI (rust-embedded/book#205)
This commit fixes a few bugs in handling of
[patch]
where multipleversion 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. Thelock
functionserves 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 checkmatches_ignoring_source
. If the latter returnstrue
then we double-check that the previous dependency is still in[patch]
, and then we let it through. This means that patches withmultiple 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 wouldcontinuously 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.
Closes #7264