found unstable fingerprints for predicates_of(core[3998]::ops::function::Fn) in Bevy

[cwboden]

I was following the Bevy 'Getting Started' tutorial here. I followed the instructions to setup the code in fast-compile mode, which involves using LLD to link and the nightly build of the Rust compiler. That setup guide is here.

Code

The code is extremely minimal, though I imagine a lot is going on behind the scenes:

use bevy::prelude::*;

fn main() {
    App::build().run();
}

Meta

rustc --version --verbose:

rustc 1.47.0 (18bf6b4f0 2020-10-07)
binary: rustc
commit-hash: 18bf6b4f01a6feaf7259ba7cdae58031af1b7b39
commit-date: 2020-10-07
host: x86_64-unknown-linux-gnu
release: 1.47.0
LLVM version: 11.0

Error output

   Compiling robot-puzzle-game-bevy v0.1.0 (/home/cwboden/robot-puzzle-game-bevy)
     Running `rustc --crate-name robot_puzzle_game_bevy --edition=2018 src/main.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type bin --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 -C metadata=ad2209ce69832b5f -C extra-filename=-ad2209ce69832b5f --out-dir /home/cwboden/robot-puzzle-game-bevy/target/debug/deps -C linker=/usr/bin/clang -C incremental=/home/cwboden/robot-puzzle-game-bevy/target/debug/incremental -L dependency=/home/cwboden/robot-puzzle-game-bevy/target/debug/deps --extern bevy=/home/cwboden/robot-puzzle-game-bevy/target/debug/deps/libbevy-108c2d5d0e0afc45.rlib -Clink-arg=-fuse-ld=lld -Zshare-generics=y -L native=/usr/lib -L native=/home/cwboden/robot-puzzle-game-bevy/target/debug/build/minimp3-sys-4639eb82c0172124/out -L native=/usr/lib -L /home/cwboden/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy-glsl-to-spirv-0.2.1/build/linux -L native=/home/cwboden/robot-puzzle-game-bevy/target/debug/build/spirv-reflect-ac54b76490ce4ac7/out -L native=/usr/lib`
thread 'rustc' panicked at 'found unstable fingerprints for predicates_of(core[3998]::ops::function::Fn)', /rustc/1705a7d64b833d1c4b69958b0627bd054e6d764b/compiler/rustc_query_system/src/query/plumbing.rs:593:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.52.0-nightly (1705a7d64 2021-03-18) running on x86_64-unknown-linux-gnu

note: compiler flags: -Z share-generics=y -C embed-bitcode=no -C debuginfo=2 -C linker=/usr/bin/clang -C incremental -C link-arg=-fuse-ld=lld --crate-type bin

note: some of the compiler flags provided by cargo are hidden

query stack during panic:
#0 [predicates_of] computing predicates of `std::ops::Fn`
#1 [vtable_methods] finding all methods for trait std::ops::Fn
end of query stack
error: could not compile `robot-puzzle-game-bevy`

Caused by:
  process didn't exit successfully: `rustc --crate-name robot_puzzle_game_bevy --edition=2018 src/main.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type bin --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 -C metadata=ad2209ce69832b5f -C extra-filename=-ad2209ce69832b5f --out-dir /home/cwboden/robot-puzzle-game-bevy/target/debug/deps -C linker=/usr/bin/clang -C incremental=/home/cwboden/robot-puzzle-game-bevy/target/debug/incremental -L dependency=/home/cwboden/robot-puzzle-game-bevy/target/debug/deps --extern bevy=/home/cwboden/robot-puzzle-game-bevy/target/debug/deps/libbevy-108c2d5d0e0afc45.rlib -Clink-arg=-fuse-ld=lld -Zshare-generics=y -L native=/usr/lib -L native=/home/cwboden/robot-puzzle-game-bevy/target/debug/build/minimp3-sys-4639eb82c0172124/out -L native=/usr/lib -L /home/cwboden/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy-glsl-to-spirv-0.2.1/build/linux -L native=/home/cwboden/robot-puzzle-game-bevy/target/debug/build/spirv-reflect-ac54b76490ce4ac7/out -L native=/usr/lib` (exit code: 101)

Backtrace

   0: rust_begin_unwind
             at /rustc/1705a7d64b833d1c4b69958b0627bd054e6d764b/library/std/src/panicking.rs:493:5
   1: std::panicking::begin_panic_fmt
             at /rustc/1705a7d64b833d1c4b69958b0627bd054e6d764b/library/std/src/panicking.rs:435:5
   2: rustc_query_system::query::plumbing::incremental_verify_ich
   3: rustc_query_system::query::plumbing::load_from_disk_and_cache_in_memory
   4: rustc_query_system::query::plumbing::get_query_impl
   5: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::predicates_of
   6: rustc_middle::ty::generics::GenericPredicates::instantiate_identity_into
   7: rustc_middle::ty::generics::GenericPredicates::instantiate_identity
   8: rustc_trait_selection::traits::object_safety::generics_require_sized_self
   9: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &mut F>::call_once
  10: <core::iter::adapters::flatten::FlatMap<I,U,F> as core::iter::traits::iterator::Iterator>::next
  11: <smallvec::SmallVec<A> as core::iter::traits::collect::Extend<<A as smallvec::Array>::Item>>::extend
  12: rustc_arena::cold_path
  13: rustc_middle::arena::Arena::alloc_from_iter
  14: rustc_trait_selection::traits::vtable_methods
  15: rustc_query_impl::<impl rustc_query_system::query::config::QueryAccessors<rustc_query_impl::plumbing::QueryCtxt> for rustc_query_impl::queries::vtable_methods>::compute
  16: rustc_middle::dep_graph::<impl rustc_query_system::dep_graph::DepKind for rustc_middle::dep_graph::dep_node::DepKind>::with_deps
  17: rustc_query_system::dep_graph::graph::DepGraph<K>::with_ignore
  18: rustc_query_system::query::plumbing::load_from_disk_and_cache_in_memory
  19: rustc_data_structures::stack::ensure_sufficient_stack
  20: rustc_query_system::query::plumbing::get_query_impl
  21: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::vtable_methods
  22: <rustc_mir::monomorphize::collector::MirNeighborCollector as rustc_middle::mir::visit::Visitor>::visit_rvalue
  23: rustc_mir::monomorphize::collector::collect_neighbours
  24: rustc_mir::monomorphize::collector::collect_items_rec
  25: rustc_mir::monomorphize::collector::collect_crate_mono_items
  26: rustc_mir::monomorphize::partitioning::collect_and_partition_mono_items
  27: rustc_query_impl::<impl rustc_query_system::query::config::QueryAccessors<rustc_query_impl::plumbing::QueryCtxt> for rustc_query_impl::queries::collect_and_partition_mono_items>::compute
  28: rustc_middle::dep_graph::<impl rustc_query_system::dep_graph::DepKind for rustc_middle::dep_graph::dep_node::DepKind>::with_deps
  29: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task_impl
  30: rustc_data_structures::stack::ensure_sufficient_stack
  31: rustc_query_system::query::plumbing::force_query_with_job
  32: rustc_query_system::query::plumbing::get_query_impl
  33: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::collect_and_partition_mono_items
  34: <rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_ssa::traits::backend::CodegenBackend>::codegen_crate
  35: rustc_interface::passes::QueryContext::enter
  36: rustc_interface::queries::Queries::ongoing_codegen
  37: rustc_interface::queries::<impl rustc_interface::interface::Compiler>::enter
  38: rustc_span::with_source_map
  39: rustc_interface::interface::create_compiler_and_run
  40: scoped_tls::ScopedKey<T>::set

[cwboden]

One step I missed from the fast-compile setup is adding these lines to <project>/.cargo/config.toml:

[target.x86_64-unknown-linux-gnu]
linker = "/usr/bin/clang"
rustflags = ["-Clink-arg=-fuse-ld=lld", "-Zshare-generics=y"]

Removing these lines stops the bug from occurring

[aDotInTheVoid]

Possibly releated to #83292

[Aaron1011]

@cwboden: Does this still happen on the latest nightly?

[cwboden]

@Aaron1011: It does not, I can no longer reproduce this problem

[FrederikP]

This just happened to me as well after following bevys fast compile setup at: https://bevyengine.org/learn/book/getting-started/setup/

I'm on the latest nightly (just installed it).

❯ cargo run
   Compiling town-blacksmith v0.1.0 (/home/user/dev/project)
thread 'rustc' panicked at 'found unstable fingerprints for predicates_of(core[3998]::ops::function::Fn): GenericPredicates { parent: None, predicates: [(Binder(TraitPredicate(<Self as std::ops::FnMut<Args>>)), /home/user/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:67:21: 67:32 (#0)), (Binder(TraitPredicate(<Args as std::marker::Sized>)), /home/user/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:67:14: 67:18 (#0)), (Binder(TraitPredicate(<Self as std::ops::Fn<Args>>)), /home/user/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:67:1: 67:32 (#0))] }', /rustc/07e0e2ec268c140e607e1ac7f49f145612d0f597/compiler/rustc_query_system/src/query/plumbing.rs:593:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.53.0-nightly (07e0e2ec2 2021-03-24) running on x86_64-unknown-linux-gnu

note: compiler flags: -Z share-generics=y -C embed-bitcode=no -C debuginfo=2 -C linker=/usr/bin/clang -C incremental -C link-arg=-fuse-ld=lld --crate-type bin

note: some of the compiler flags provided by cargo are hidden

query stack during panic:
#0 [predicates_of] computing predicates of `std::ops::Fn`
#1 [vtable_methods] finding all methods for trait std::ops::Fn
end of query stack
error: could not compile `town-blacksmith`

To learn more, run the command again with --verbose.

It doesn't happen if I comment out in .cargo/config.toml:

# [target.x86_64-unknown-linux-gnu]
# linker = "/usr/bin/clang"
# rustflags = ["-Clink-arg=-fuse-ld=lld", "-Zshare-generics=y"]

[wesleywiser]

Thanks for filing the bug report! We just shipped a patch release to work around this issue and are currently triaging related issues related to ensure each underlying problem gets resolved. Since this appears to be a duplicate of #83259, I'm going to close in favor of that issue.