-
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
[patch] with duplicate values causes panic #7264
Labels
A-dependency-resolution
Area: dependency resolution and the resolver
A-patch
Area: [patch] table override
C-bug
Category: bug
Comments
ehuss
added
C-bug
Category: bug
A-dependency-resolution
Area: dependency resolution and the resolver
A-patch
Area: [patch] table override
labels
Aug 19, 2019
Confirmed I hit this when testing #7263 :
|
Why shouldn't you have 2 patches to the same location? It seems like it could work -- maybe you need two versions of same code without feature unification? I could always fork the repo a second time without changes, and then it would be expected to work, right? |
bors
added a commit
that referenced
this issue
Aug 27, 2019
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-dependency-resolution
Area: dependency resolution and the resolver
A-patch
Area: [patch] table override
C-bug
Category: bug
Problem
A
[patch]
table with multiple values usingpackage
can cause a panic.Results in:
Notes
This appears to happen ever since package renaming was introduced up to latest nightly-2019-08-19.
Obviously you shouldn't have two patches to the same location, but it shouldn't panic.
The text was updated successfully, but these errors were encountered: