Skip to content
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

Resolution with [patch] isn't preserving "one major version per source" restriction #7117

Closed
alexcrichton opened this issue Jul 10, 2019 · 0 comments · Fixed by #7118
Closed
Labels
A-patch Area: [patch] table override

Comments

@alexcrichton
Copy link
Member

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]
fn patch_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();
}
@alexcrichton alexcrichton added the A-patch Area: [patch] table override label Jul 10, 2019
alexcrichton added a commit to alexcrichton/cargo that referenced this issue Jul 10, 2019
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 rust-lang#7117
bors added a commit that referenced this issue Jul 12, 2019
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-patch Area: [patch] table override
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant