Skip to content

"unstable fingerprints for predicates_of" with Clone trait #84735

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

Closed
AE1020 opened this issue Apr 30, 2021 · 2 comments
Closed

"unstable fingerprints for predicates_of" with Clone trait #84735

AE1020 opened this issue Apr 30, 2021 · 2 comments
Labels
A-incr-comp Area: Incremental compilation C-bug Category: This is a bug. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@AE1020
Copy link
Contributor

AE1020 commented Apr 30, 2021

This appears to be a transient error in an incremental build. I wrote up this issue and saved the stack when I got it. But when I did cargo clean and then cargo build it would not reproduce.

I had done rustup default nightly at some point, probably (?) without a cargo clean. There had been successful builds after that with nightly, but perhaps never a clean one. In case that had something to do with it, I tried:

$ rustup default stable
$ cargo clean
$ cargo build

# make change here

$ rustup default nightly
$ cargo build

But that didn't reproduce it either. :-(


The change was to manually implement a Clone trait that had previously been derived, in order to log or set breakpoints when a clone of a particular struct was made.

The patch I'm trying is to the Firecracker VMM, specifically to a struct in mmio.rs.

(Note: I don't have any Rust experience to speak of--and am merely trying to get some experience with it by poking around with Firecracker. But perhaps that makes me good at writing unexpected things that will crash Rustc.)

Code

#[derive(Debug, PartialEq, Versionize)]  // previously derived Clone
pub struct MMIODeviceInfo {
    pub addr: u64,
    pub len: u64,
    pub irqs: Vec<u32>,
}

impl Clone for MMIODeviceInfo {  // I added this "hooked" Clone
    fn clone(&self) -> Self {
        println!("!!! CLONING {}", self.addr);

        // Question: is this equivalent to what the derive(Clone) makes?
        MMIODeviceInfo {
            addr: self.addr.clone(),
            len: self.len.clone(),
            irqs: self.irqs.clone()
        }
    }
}

Meta

rustc 1.53.0-nightly (42816d61e 2021-04-24)
binary: rustc
commit-hash: 42816d61ead7e46d462df997958ccfd514f8c21c
commit-date: 2021-04-24
host: x86_64-unknown-linux-gnu
release: 1.53.0-nightly
LLVM version: 12.0.0

Error output

thread 'rustc' panicked at 'assertion failed: `(left == right)`
  left: `Some(Fingerprint(850694786735502876, 7070618143976680221))`,
 right: `Some(Fingerprint(4204111565215846862, 483459271662230500))`: found unstable fingerprints for predicates_of(core[ec89]::clone::Clone): GenericPredicates { parent: None, predicates: [(Binder(TraitPredicate(<Self as std::marker::Sized>), []), /home/ae1020/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/clone.rs:108:18: 108:23 (#0)), (Binder(TraitPredicate(<Self as std::clone::Clone>), []), /home/ae1020/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/clone.rs:108:1: 108:23 (#0))] }', /rustc/42816d61ead7e46d462df997958ccfd514f8c21c/compiler/rustc_query_system/src/query/plumbing.rs:593:5
Backtrace

   0: rust_begin_unwind
             at /rustc/42816d61ead7e46d462df997958ccfd514f8c21c/library/std/src/panicking.rs:493:5
   1: core::panicking::panic_fmt
             at /rustc/42816d61ead7e46d462df997958ccfd514f8c21c/library/core/src/panicking.rs:92:14
   2: core::panicking::assert_failed_inner
   3: core::panicking::assert_failed
   4: rustc_query_system::query::plumbing::incremental_verify_ich
   5: rustc_query_system::query::plumbing::load_from_disk_and_cache_in_memory
   6: rustc_query_system::query::plumbing::get_query_impl
   7: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::predicates_of
   8: rustc_trait_selection::traits::wf::WfPredicates::nominal_obligations
   9: rustc_trait_selection::traits::wf::WfPredicates::compute_trait_ref
  10: rustc_trait_selection::traits::wf::trait_obligations
  11: rustc_infer::infer::InferCtxtBuilder::enter
  12: rustc_typeck::check::wfcheck::check_item_well_formed
  13: rustc_middle::dep_graph::<impl rustc_query_system::dep_graph::DepKind for rustc_middle::dep_graph::dep_node::DepKind>::with_deps
  14: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task_impl
  15: rustc_query_system::query::plumbing::force_query_with_job
  16: rustc_query_system::query::plumbing::get_query_impl
  17: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::check_item_well_formed
  18: <rustc_typeck::check::wfcheck::CheckTypeWellFormedVisitor as rustc_hir::intravisit::Visitor>::visit_item
  19: rustc_data_structures::sync::par_for_each_in
  20: rustc_hir::hir::Crate::par_visit_all_item_likes
  21: rustc_session::session::Session::track_errors
  22: rustc_typeck::check_crate
  23: rustc_interface::passes::analysis
  24: rustc_middle::dep_graph::<impl rustc_query_system::dep_graph::DepKind for rustc_middle::dep_graph::dep_node::DepKind>::with_deps
  25: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task_impl
  26: rustc_data_structures::stack::ensure_sufficient_stack
  27: rustc_query_system::query::plumbing::force_query_with_job
  28: rustc_query_system::query::plumbing::get_query_impl
  29: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::analysis
  30: rustc_interface::passes::QueryContext::enter
  31: rustc_interface::queries::<impl rustc_interface::interface::Compiler>::enter
  32: rustc_span::with_source_map
  33: rustc_interface::interface::create_compiler_and_run
  34: scoped_tls::ScopedKey<T>::set
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

@AE1020 AE1020 added C-bug Category: This is a bug. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Apr 30, 2021
@jyn514 jyn514 added the A-incr-comp Area: Incremental compilation label Apr 30, 2021
@Aaron1011
Copy link
Member

Duplicate of #84341

@Aaron1011 Aaron1011 marked this as a duplicate of #84341 May 1, 2021
@Aaron1011
Copy link
Member

This should be fixed in the latest nightly

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-incr-comp Area: Incremental compilation C-bug Category: This is a bug. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

3 participants