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

ehuss · 2019-10-01T20:41:19Z

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 f4d1b77

The text was updated successfully, but these errors were encountered:

Eh2406 · 2019-10-02T14:56:21Z

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 · 2020-07-21T03:51:32Z

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 · 2021-02-04T08:24:10Z

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.

cargo update fails with 'not currently active!?'. A workaround is here rust-lang/cargo#7463.

Noah-Kennedy · 2022-03-31T16:59:05Z

I've experienced this issue as well.

Noah-Kennedy · 2022-03-31T16:59:28Z

@rustbot claim

pimeys · 2022-09-07T14:52:12Z

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

expenses · 2022-10-03T10:25:50Z

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.

Currently, we are importing the `ahash` crate for only one reason: to test that CachingSession works with custom hasher implementations. The custom hasher quality doesn't matter at all in this test, so it's very easy to write own implementation for testing purposes, rendering the dependency on `ahash` obsolete. The change was prompted by a report from one of our users which use a fork of the driver and managed to trigger a bug in cargo - most likely this one: rust-lang/cargo#7463 . The most likely cause was that the project specified a different, non-compatible version of ahash in the dependencies than the one in scylla's dev-dependencies. While it doesn't fix the cargo bug and it can still happen with other dev-dependencies, the bug should no longer happen with conflicting `ahash`. Moreover, removing an unneeded depdencency from a project is a good motivation in itself.

declantsien · 2023-01-30T02:40:25Z

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.

rust-lang/cargo#7463

Fixed Cargo nonsense rust-lang/cargo#7463 rework winit_term configuration

relocate crates out dir wip fix decouple winit/webrender set surfman size fmt decouple input_processor decouple window from output cleanup wr_render_init move scale_factor to display_info move color bits to display info new canvas from frame directly some clean up window id usin raw handle wr output decouput font wip wip wr output decouput font build: use rust --cfg Fixed Cargo nonsense rust-lang/cargo#7463 rework winit_term configuration

Fixed Cargo nonsense rust-lang/cargo#7463 rework winit_term configuration

relocate crates out dir wip fix decouple winit/webrender set surfman size fmt decouple input_processor decouple window from output cleanup wr_render_init move scale_factor to display_info move color bits to display info new canvas from frame directly some clean up window id usin raw handle wr output decouput font wip wip wr output decouput font build: use rust --cfg Fixed Cargo nonsense rust-lang/cargo#7463 rework winit_term configuration build pgtk with webrender configure pgtk with webrender

webrender: Fix missing wr-frame-edges winit and webrender decouple relocate crates out dir wip fix decouple winit/webrender set surfman size fmt decouple input_processor decouple window from output cleanup wr_render_init move scale_factor to display_info move color bits to display info new canvas from frame directly some clean up window id usin raw handle wr output decouput font wip wip wr output decouput font build: use rust --cfg Fixed Cargo nonsense rust-lang/cargo#7463 rework winit_term configuration build pgtk with webrender configure pgtk with webrender

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 · 2023-05-27T13:34:48Z

Should be fixed by #11770 in 1.70.0. Thanks for the report and the test example!

ehuss added C-bug Category: bug A-patch Area: [patch] table override labels Oct 1, 2019

ehuss mentioned this issue Oct 1, 2019

Panic when patching dependency #7346

Closed

Eh2406 mentioned this issue Oct 1, 2020

Panic on curious [patch] combination #8745

Open

boxdot added a commit to boxdot/tonic-ws-transport that referenced this issue Aug 27, 2021

Check-in Cargo.lock to mitigate cargo build errors.

d37f348

cargo update fails with 'not currently active!?'. A workaround is here rust-lang/cargo#7463.

boxdot added a commit to boxdot/tonic-ws-transport that referenced this issue Aug 27, 2021

Check-in Cargo.lock to mitigate cargo build errors.

f4d8b40

cargo update fails with 'not currently active!?'. A workaround is here rust-lang/cargo#7463.

rustbot assigned Noah-Kennedy Mar 31, 2022

weihanglo mentioned this issue Nov 10, 2022

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

Closed

piodul mentioned this issue Jan 18, 2023

caching_session: use custom hasher instead of ahash in tests scylladb/scylla-rust-driver#625

Merged

6 tasks

declantsien added a commit to declantsien/emacs-ng that referenced this issue Feb 2, 2023

Fixed Cargo nonsense

f9f9b3a

rust-lang/cargo#7463

declantsien added a commit to declantsien/emacs-ng that referenced this issue Feb 10, 2023

Fixed Cargo nonsense

01abff3

rust-lang/cargo#7463

declantsien added a commit to declantsien/emacs-ng that referenced this issue Feb 11, 2023

build: use rust --cfg

291b250

Fixed Cargo nonsense rust-lang/cargo#7463 rework winit_term configuration

declantsien added a commit to 2e0byo/emacs-ng that referenced this issue Feb 21, 2023

build: use rust --cfg

cb74336

Fixed Cargo nonsense rust-lang/cargo#7463 rework winit_term configuration

Eh2406 mentioned this issue Feb 25, 2023

patch can conflict on not activated packages #11770

Merged

weihanglo closed this as completed May 27, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

ehuss commented Oct 1, 2019 •

edited by rustbot

Eh2406 commented Oct 2, 2019

xlc commented Jul 21, 2020 •

edited

simonbuchan commented Feb 4, 2021 •

edited

Noah-Kennedy commented Mar 31, 2022

Noah-Kennedy commented Mar 31, 2022

pimeys commented Sep 7, 2022

expenses commented Oct 3, 2022

declantsien commented Jan 30, 2023

weihanglo commented May 27, 2023

Panic with [patch] and conflicting equal versions. #7463

Panic with [patch] and conflicting equal versions. #7463

Comments

ehuss commented Oct 1, 2019 • edited by rustbot

Eh2406 commented Oct 2, 2019

xlc commented Jul 21, 2020 • edited

simonbuchan commented Feb 4, 2021 • edited

Noah-Kennedy commented Mar 31, 2022

Noah-Kennedy commented Mar 31, 2022

pimeys commented Sep 7, 2022

expenses commented Oct 3, 2022

declantsien commented Jan 30, 2023

weihanglo commented May 27, 2023

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

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

ehuss commented Oct 1, 2019 •

edited by rustbot

xlc commented Jul 21, 2020 •

edited

simonbuchan commented Feb 4, 2021 •

edited