-
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
thread 'main' panicked at 'not currently active!?', src/tools/cargo/src/cargo/core/resolver/mod.rs:832:20 #11336
Comments
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();
} |
I suspect this has the same root cause as #7463. |
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? |
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.
Fixed by #11770 in 1.70.0. Thanks for the report and reproducer! |
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
git clone https://gitlab.com/w0lff/cargo-issue-11012.git
cargo build
Possible Solution(s)
No response
Notes
The
=
in the version field of thewayland-client
crate is needed now because the maintainer published newer versions. Without it cargo fails with an error and does not panic anymore.Version
The text was updated successfully, but these errors were encountered: