found unstable fingerprints for evaluate_obligation - Only occurs after the previous build was successful

[00alia00]

cargo clean
cargo build <-- works

small change
cargo build <-- fails

Meta

rustc --version --verbose:

rustc 1.53.0-nightly (07e0e2ec2 2021-03-24)
binary: rustc
commit-hash: 07e0e2ec268c140e607e1ac7f49f145612d0f597
commit-date: 2021-03-24
host: x86_64-pc-windows-msvc
release: 1.53.0-nightly
LLVM version: 12.0.0

Console

PS C:\learn_rust> $Env:RUST_BACKTRACE=1; cargo build
   Compiling rust_test v0.1.0 (C:\learn_rust)
thread 'rustc' panicked at 'found unstable fingerprints for evaluate_obligation(3ed5fc901ea1a3ff-2784eb2c255cbcc7): Ok(EvaluatedToOk)', /rustc/07e0e2ec268c140e607e1ac7f49f145612d0f597\compiler\rustc_query_system\src\query\plumbing.rs:593:5
stack backtrace:
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose 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-pc-windows-msvc

note: compiler flags: -Z share-generics=y -C embed-bitcode=no -C debuginfo=2 -C linker=rust-lld.exe -C incremental --crate-type bin

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

Backtrace

query stack during panic:
#0 [evaluate_obligation] evaluating trait selection obligation `bevy_rapier2d::nalgebra::Isometry<f32, bevy_rapier2d::nalgebra::U2, bevy_rapier2d::nalgebra::Unit<bevy_rapier2d::nalgebra::Complex<f32>>>: std::marker::Send`
#1 [typeck] type-checking `spawn_bat`
#2 [typeck_item_bodies] type-checking all item bodies
#3 [analysis] running analysis passes on this crate
end of query stack

[fee1-dead]

Try using the latest nightly and see if you can reproduce the issue.

@rustbot label: A-incr-comp

[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 #83538, I'm going to close in favor of that issue.