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

thread 'main' panicked at 'not currently active!?', src/tools/cargo/src/cargo/core/resolver/mod.rs:832:20 #11336

Closed
hw0lff opened this issue Nov 4, 2022 · 4 comments
Labels
A-dependency-resolution Area: dependency resolution and the resolver A-patch Area: [patch] table override C-bug Category: bug

Comments

@hw0lff
Copy link

hw0lff commented Nov 4, 2022

Problem

When building the linked minimal reproducible example cargo panics.

This bug got reported before in #11012 . However, they were not able to reproduce the error.
I found a minimal reproducible example.

Steps

  1. git clone https://gitlab.com/w0lff/cargo-issue-11012.git
  2. cargo build

Possible Solution(s)

No response

Notes

The = in the version field of the wayland-client crate is needed now because the maintainer published newer versions. Without it cargo fails with an error and does not panic anymore.

Version

cargo 1.65.0 (4bc8f24d3 2022-10-20)
release: 1.65.0
commit-hash: 4bc8f24d3e899462e43621aab981f6383a370365
commit-date: 2022-10-20
host: x86_64-unknown-linux-gnu
libgit2: 1.5.0 (sys:0.15.0 vendored)
libcurl: 7.83.1-DEV (sys:0.4.55+curl-7.83.1 vendored ssl:OpenSSL/1.1.1q)
os: Arch Linux Rolling Release [64-bit]
@weihanglo
Copy link
Member

Thanks for your report!

It is definitely a bug that Cargo panics. From the other angle, it also does things partially correctly. Your package depends on two SemVer-compatible versions of a single package, which is not currently possible in Cargo.

I've got a minimal example in Cargo's own test dialect more or less the same as your example. Let's investigate it more!

Expand to see the example
#[cargo_test]
fn mismatched_version2() {
    Package::new("qux", "0.1.0-beta.1").publish();
    Package::new("qux", "0.1.0-beta.2").publish();
    Package::new("bar", "0.1.0").dep("qux", "=0.1.0-beta.1").publish();
    let p = project()
        .file(
            "Cargo.toml",
            r#"
                 [package]
                 name = "foo"
                 version = "0.1.0"

                 [dependencies]
                 bar = "0.1.0"
                 qux = "=0.1.0-beta.2" # still panic without `=`

                 [patch.crates-io]
                 qux = { path = "qux" }
            "#,
        )
        .file("src/lib.rs", "")
        .file(
            "qux/Cargo.toml",
            r#"
                [package]
                name = "qux"
                version = "0.1.0-beta.1"
            "#,
        )
        .file("qux/src/lib.rs", "")
        .build();

    p.cargo("check")
        .with_status(101)
        .with_stderr("")
        .run();
}

@weihanglo weihanglo added A-dependency-resolution Area: dependency resolution and the resolver A-patch Area: [patch] table override labels Nov 7, 2022
@weihanglo
Copy link
Member

I suspect this has the same root cause as #7463.

@tomasro27
Copy link

I am seeing the same issue as well with a combination of crates, but it is hard to debug given that cargo panics and does not update lock file.

Any updates on fixing the panic?

bors added a commit that referenced this issue Mar 2, 2023
patch can conflict on not activated packages

### What does this PR try to resolve?

In the resolver there is a data structure called a `conflicting_activations`, which records all the reasons a "better" version was not picked for the package being resolved. Normally, these are packages that are currently active that for one reason or another block one of the other versions. Several optimizations assumed that this was always true, even going so far as to use `.expect`. This was a mistake because when there's a `patch` involved there can be conflicts on a version that is not selected. So the correct behavior is to fall back to skip the optimizations and try all versions when a `conflicting_activations` are not active.

### How should we test and review this PR?

This adds two automated tests based on the reproductions in #7463 and #11336. So the test suite now covers this case. It can also be tested by reconstructing the repositories originally reported in those issues.

### Additional information

It could be that in the long term the correct fix is to figure out how to support patch without having a conflicting activation that is not activated. But that would be a much bigger change. And for now this assumption is only used in optimizations, so this gets people unstuck.
@weihanglo
Copy link
Member

Fixed by #11770 in 1.70.0. Thanks for the report and reproducer!

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
Projects
None yet
Development

No branches or pull requests

3 participants