You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Cargo has the restriction that only one semver-compatible version is allowed per source. Using [patch] however allows you to subvert this restriction by accident, causing issues with using [patch]. When using [patch] the major version pulled in from [patch] is not considered source-equal with other versions from the same source, seemingly allowing two major versions to be in the crate graph!
This bug is likely in the resolver where during the check for whether a package can be activated we'll need to add some logic to the source check to take into account [patch] (or similar)
An example test showing this failure is:
#[cargo_test]fnpatch_older(){Package::new("baz","1.0.2").publish();let p = project().file("Cargo.toml",r#" [package] name = "foo" version = "0.1.0" [dependencies] bar = { path = 'bar' } baz = "=1.0.1" [patch.crates-io] baz = { path = "./baz" } "#,).file("src/lib.rs","").file("bar/Cargo.toml",r#" [project] name = "bar" version = "0.5.0" authors = [] [dependencies] baz = "1.0.0" "#,).file("bar/src/lib.rs","").file("baz/Cargo.toml",r#" [project] name = "baz" version = "1.0.1" authors = [] "#,).file("baz/src/lib.rs","").build();
p.cargo("build").with_stderr("\[UPDATING] [..][COMPILING] baz v1.0.1 [..][COMPILING] bar v0.5.0 [..][COMPILING] foo v0.5.0 [..][FINISHED] [..]",).run();}
The text was updated successfully, but these errors were encountered:
This commit updates the resolver to ensure that it recognizes conflicts
when `[patch]` is used to augment an older version of what's already in
a source, for example. Previously the deduplication based on
semver-compatible versions didn't actually work when `[patch]` was used.
This meant that when you used `[patch]` it might not transitively affect
the entire crate graph, instead just giving you a version of a
dependency and everyone else. This violates the intention of `[patch]`!
The fix here is to catch this use case happening, when a `Dependency`
source specification mismatches an activated package we need to list a
second activation in the resolver to prevent major versions from being
selected from both the original source as well as the source of the id.
Closesrust-lang#7117
Handle activation conflicts for `[patch]` sources
This commit updates the resolver to ensure that it recognizes conflicts
when `[patch]` is used to augment an older version of what's already in
a source, for example. Previously the deduplication based on
semver-compatible versions didn't actually work when `[patch]` was used.
This meant that when you used `[patch]` it might not transitively affect
the entire crate graph, instead just giving you a version of a
dependency and everyone else. This violates the intention of `[patch]`!
The fix here is to catch this use case happening, when a `Dependency`
source specification mismatches an activated package we need to list a
second activation in the resolver to prevent major versions from being
selected from both the original source as well as the source of the id.
Closes#7117
Cargo has the restriction that only one semver-compatible version is allowed per source. Using
[patch]
however allows you to subvert this restriction by accident, causing issues with using[patch]
. When using[patch]
the major version pulled in from[patch]
is not considered source-equal with other versions from the same source, seemingly allowing two major versions to be in the crate graph!This bug is likely in the resolver where during the check for whether a package can be activated we'll need to add some logic to the source check to take into account
[patch]
(or similar)An example test showing this failure is:
The text was updated successfully, but these errors were encountered: