Panic with `[patch]` and conflicting equal versions.

[ehuss]

When testing out #7346, I came across a strange case where the resolver panics. I neglected to update every version across multiple packages in a workspace. Below is a fairly minimal reproduction. Notice that it has both =0.1.0 and =0.1.1.

#[cargo_test]
fn patch_eq_conflict_panic() {
    Package::new("bar", "0.1.0").publish();
    Package::new("bar", "0.1.1").publish();
    let p = project()
        .file("Cargo.toml",
            r#"
                [package]
                name = "foo"
                version = "0.1.0"

                [dependencies]
                bar = "=0.1.0"

                [dev-dependencies]
                bar = "=0.1.1"

                [patch.crates-io]
                bar = {path="bar"}
            "#)
        .file("src/lib.rs", "")
        .file("bar/Cargo.toml", &basic_manifest("bar", "0.1.1"))
        .file("bar/src/lib.rs", "")
        .build();

    p.cargo("generate-lockfile").run();
}

Fails with:

thread 'main' panicked at 'not currently active!?', src/libcore/option.rs:1190:5
stack backtrace:
  ..snip..
  15: core::option::Option<T>::expect
             at /rustc/084beb83e0e87d673d5fabc844d28e8e8ae2ab4c/src/libcore/option.rs:345
  16: cargo::core::resolver::generalize_conflicting::{{closure}}
             at src/cargo/core/resolver/mod.rs:871
  17: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &mut F>::call_once
             at /rustc/084beb83e0e87d673d5fabc844d28e8e8ae2ab4c/src/libcore/ops/function.rs:275
  18: core::option::Option<T>::map
             at /rustc/084beb83e0e87d673d5fabc844d28e8e8ae2ab4c/src/libcore/option.rs:447
  19: <core::iter::adapters::Map<I,F> as core::iter::traits::iterator::Iterator>::next
             at /rustc/084beb83e0e87d673d5fabc844d28e8e8ae2ab4c/src/libcore/iter/adapters/mod.rs:710
  20: core::iter::traits::iterator::fold1
             at /rustc/084beb83e0e87d673d5fabc844d28e8e8ae2ab4c/src/libcore/iter/traits/iterator.rs:2967
  21: core::iter::traits::iterator::Iterator::max_by
             at /rustc/084beb83e0e87d673d5fabc844d28e8e8ae2ab4c/src/libcore/iter/traits/iterator.rs:2259
  22: core::iter::traits::iterator::Iterator::max
             at /rustc/084beb83e0e87d673d5fabc844d28e8e8ae2ab4c/src/libcore/iter/traits/iterator.rs:2174
  23: cargo::core::resolver::generalize_conflicting
             at src/cargo/core/resolver/mod.rs:869
  24: cargo::core::resolver::activate_deps_loop::{{closure}}
             at src/cargo/core/resolver/mod.rs:288
  25: core::result::Result<T,E>::or_else
             at /rustc/084beb83e0e87d673d5fabc844d28e8e8ae2ab4c/src/libcore/result.rs:761
  26: cargo::core::resolver::activate_deps_loop
             at src/cargo/core/resolver/mod.rs:257
  27: cargo::core::resolver::resolve
             at src/cargo/core/resolver/mod.rs:137
  28: cargo::ops::resolve::resolve_with_previous
             at src/cargo/ops/resolve.rs:338
  29: cargo::ops::cargo_generate_lockfile::generate_lockfile
             at src/cargo/ops/cargo_generate_lockfile.rs:24
  ..snip..

I think it should fail with an error like the non-patch version ("failed to select a version for bar").

Currently on latest master f4d1b774b555774deb0f7f1ae68141eace51b062

[Eh2406]

This is definitely a bug. Thank you for the clere report and test case.

At one level the panic is caused by .expect("not currently active!?"), witch should be a debug_assert not an expect. I.E. in production if we get to this bad state we can safely return none from generalize_conflicting. The next question is how we ended up in that bad state. How did we end up with a conflict of the form we can't be activated because x is active while x is not activated.

[xlc]

I am getting same issue

$ RUST_BACKTRACE=full cargo check --tests
thread 'main' panicked at 'not currently active!?', src/tools/cargo/src/cargo/core/resolver/mod.rs:824:36
stack backtrace:
   0:        0x10223bb0e - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h13e6f26430148ff2
   1:        0x10226850c - core::fmt::write::h45a9bd04db15c24f
   2:        0x102232d29 - std::io::Write::write_fmt::h8ae61696f13218d5
   3:        0x10223f795 - std::panicking::default_hook::{{closure}}::hc98fe2390b6284e5
   4:        0x10223f4d2 - std::panicking::default_hook::h9a63cea866a4c14a
   5:        0x10223fcf5 - std::panicking::rust_panic_with_hook::h4d446ca45c8e1faa
   6:        0x10223f8c2 - rust_begin_unwind
   7:        0x1022c0b1f - core::panicking::panic_fmt::hda969e68cfcc1b10
   8:        0x1022c09aa - core::option::expect_failed::h590abf689f1e3bca
   9:        0x101e0318b - cargo::core::resolver::activate_deps_loop::h0e09d69184277aa5
  10:        0x101dfdc5f - cargo::core::resolver::resolve::h27fe09151b0c1150
  11:        0x101b66ebc - cargo::ops::resolve::resolve_with_previous::h52cafbe4b5e4d418
  12:        0x101b63c99 - cargo::ops::resolve::resolve_ws_with_opts::h90af86655fad5879
  13:        0x101b4e92b - cargo::ops::cargo_compile::create_bcx::h5f9a71f3a149c25a
  14:        0x101b4e08e - cargo::ops::cargo_compile::compile_ws::haaa353949a78402d
  15:        0x101b4df9f - cargo::ops::cargo_compile::compile::hbb33c978ef4058be
  16:        0x1019e76fe - cargo::commands::check::exec::h2860a3712e92316e
  17:        0x101a2d642 - cargo::cli::main::h00d91b61b2224104
  18:        0x101a39541 - cargo::main::h06d3373527355d7d
  19:        0x101a122f6 - std::rt::lang_start::{{closure}}::h434704a37f9645b1
  20:        0x102240089 - std::rt::lang_start_internal::hecbcda5e1a75a865
  21:        0x101a3bab9 - main

$ cargo -V
cargo 1.46.0-nightly (fede83ccf 2020-07-02)

---

Found out the cause, I had

paths = ["/Users/xiliangchen/projects/substrate"] in my ~/.cargo/config while building /Users/xiliangchen/projects/substrate and caused this issue.

[simonbuchan]

I hit the same with:

[patch.crates-io]
tokio = { git = "https://github.com/blackbeam/tokio", branch = "named-pipes" }

as that branch is version 1.0.1, while the current Cargo.lock version was 1.1.1. Fix was to comment out the patch, run cargo update -p tokio --precise 1.0.1, then uncomment.

[Noah-Kennedy]

I've experienced this issue as well.

[Noah-Kennedy]

@rustbot claim

[pimeys]

Just got this error when trying to patch something in a huge workspace.

[expenses]

I just got this error. Backtrace:

thread 'main' panicked at 'not currently active!?', src/tools/cargo/src/cargo/core/resolver/mod.rs:832:36
stack backtrace:
   0: rust_begin_unwind
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/panicking.rs:142:14
   2: core::panicking::panic_display
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/panicking.rs:72:5
   3: core::panicking::panic_str
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/panicking.rs:56:5
   4: core::option::expect_failed
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/option.rs:1874:5
   5: cargo::core::resolver::activate_deps_loop
   6: cargo::core::resolver::resolve
   7: cargo::ops::resolve::resolve_with_previous
   8: cargo::ops::resolve::resolve_with_registry
   9: cargo::ops::resolve::resolve_ws_with_opts
  10: cargo::ops::cargo_compile::create_bcx
  11: cargo::ops::cargo_compile::compile_ws
  12: cargo::ops::cargo_compile::compile
  13: cargo::ops::cargo_run::run
  14: cargo::commands::run::exec
  15: cargo::cli::main
  16: cargo::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[declantsien]

Found out the cause, I had

paths = ["/Users/xiliangchen/projects/substrate"] in my ~/.cargo/config while building /Users/xiliangchen/projects/substrate and caused this issue.

This saved my day. Thanks.

[weihanglo]

Should be fixed by https://github.com/rust-lang/cargo/pull/11770 in 1.70.0. Thanks for the report and the test example!