Unstable fingerprints in `evaluate_obligation`

[Noratrieb]

Code

https://github.com/Noratrieb/evaluate_obligation-fingerprints

All credits for running into this and creating an initial reproduction and minimization goes to @muja via the Rust Community Discord, I just picked it up and continued minimizing it.

This is a reliable reproduction (requires -Zincremental-verify-ich though, the original code didn't but that flag just makes reproductions more reliable). It's not yet quite minimal, some futures traits and types are still around, but it's close.

The helper attribute from the proc macro is very important. It seems likely that this is somehow related to the span of the helper attribute or something like that, though it seems extremely strange to me how this manifests in evaluate_obligation inside all those futures traits when a span and proc macro attribute are that relevant.

Meta

rustc --version --verbose:

rustc 1.92.0-nightly (53a741fc4 2025-10-16)
binary: rustc
commit-hash: 53a741fc4b8cf2d8e7b1b2336ed8edf889db84f4
commit-date: 2025-10-16
host: x86_64-unknown-linux-gnu
release: 1.92.0-nightly
LLVM version: 21.1.3

Error output

error: internal compiler error: encountered incremental compilation error with evaluate_obligation(dfb8c4a5e4e9dc3b-cf2924ff30264435)
  |
  = help: This is a known issue with the compiler. Run `cargo clean -p reproduction` or `cargo clean` to allow your project to compile
  = note: please follow the instructions below to create a bug report with the provided information
  = note: see <https://github.com/rust-lang/rust/issues/84970> for more information


thread 'rustc' (308288) panicked at /rustc-dev/53a741fc4b8cf2d8e7b1b2336ed8edf889db84f4/compiler/rustc_query_system/src/query/plumbing.rs:739:9:
Found unstable fingerprints for evaluate_obligation(dfb8c4a5e4e9dc3b-cf2924ff30264435): Ok(EvaluatedToOk)

error: 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: please make sure that you have updated to the latest nightly

note: rustc 1.92.0-nightly (53a741fc4 2025-10-16) running on x86_64-unknown-linux-gnu

note: compiler flags: --crate-type bin -C embed-bitcode=no -C debuginfo=2 -C linker=/nix/store/d6syhmcp4rldmcc9bk42zssndi4q7kwq-clang-wrapper-21.1.1/bin/clang -C incremental=[REDACTED] -Z incremental-verify-ich

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

query stack during panic:
#0 [evaluate_obligation] evaluating trait selection obligation `AndThen<{async block@src/main.rs:43:25: 43:30}, {async closure@src/main.rs:43:53: 43:62}>: core::future::future::Future`
#1 [type_op_prove_predicate] evaluating `type_op_prove_predicate` `ProvePredicate { predicate: Binder { value: WellFormed(Term::Ty(&'^c_0 mut MaybeDone<AndThen<Coroutine(DefId(0:41 ~ reproduction[db3c]::bar_baz::{closure#0}::{closure#0}), [(), core::future::ResumeTy, (), core::result::Result<(), ()>, ()]), CoroutineClosure(DefId(0:42 ~ reproduction[db3c]::bar_baz::{closure#0}::{closure#1}), [i8, Binder { value: extern "RustCall" fn(core::future::ResumeTy, ((),)) -> ((), core::result::Result<(), ()>), bound_vars: [] }, (), Binder { value: fn(), bound_vars: [Region(BrEnv)] }])>>)), bound_vars: [] } }`
#2 [mir_borrowck] borrow-checking `bar_baz`
#3 [mir_drops_elaborated_and_const_checked] elaborating drops for `bar_baz::{closure#0}::{closure#3}`
#4 [analysis] running analysis passes on this crate
end of query stack

backtrace

stack backtrace:
   0: __rustc::rust_begin_unwind
   1: core::panicking::panic_fmt
   2: rustc_query_system::query::plumbing::incremental_verify_ich_failed::<rustc_middle::ty::context::TyCtxt>
   3: rustc_query_system::query::plumbing::try_execute_query::<rustc_query_impl::DynamicConfig<rustc_query_system::query::caches::DefaultCache<rustc_type_ir::canonical::CanonicalQueryInput<rustc_middle::ty::context::TyCtxt, rustc_middle::ty::ParamEnvAnd<rustc_middle::ty::predicate::Predicate>>, rustc_middle::query::erase::Erased<[u8; 2]>>, false, false, false>, rustc_query_impl::plumbing::QueryCtxt, true>
   4: <rustc_trait_selection::traits::fulfill::FulfillProcessor as rustc_data_structures::obligation_forest::ObligationProcessor>::process_obligation
   5: <rustc_data_structures::obligation_forest::ObligationForest<rustc_trait_selection::traits::fulfill::PendingPredicateObligation>>::process_obligations::<rustc_trait_selection::traits::fulfill::FulfillProcessor>
   6: <rustc_trait_selection::traits::engine::ObligationCtxt>::make_canonicalized_query_response::<()>
   7: rustc_traits::type_op::type_op_prove_predicate
      [... omitted 2 frames ...]
   8: <rustc_borrowck::type_check::TypeChecker>::fully_perform_op::<(), rustc_middle::ty::ParamEnvAnd<rustc_middle::traits::query::type_op::ProvePredicate>>
   9: <rustc_borrowck::type_check::TypeChecker as rustc_middle::mir::visit::Visitor>::visit_operand
  10: <rustc_borrowck::type_check::TypeChecker as rustc_middle::mir::visit::Visitor>::visit_body
  11: rustc_borrowck::type_check::type_check
  12: <rustc_borrowck::root_cx::BorrowCheckRootCtxt>::do_mir_borrowck
  13: rustc_borrowck::mir_borrowck
      [... omitted 1 frame ...]
  14: rustc_mir_transform::mir_drops_elaborated_and_const_checked
      [... omitted 1 frame ...]
  15: <rustc_middle::ty::context::TyCtxt>::par_hir_body_owners::<rustc_interface::passes::run_required_analyses::{closure#1}::{closure#0}>::{closure#0}
  16: rustc_interface::passes::analysis
      [... omitted 1 frame ...]
  17: <rustc_interface::passes::create_and_enter_global_ctxt<core::option::Option<rustc_interface::queries::Linker>, rustc_driver_impl::run_compiler::{closure#0}::{closure#2}>::{closure#2} as core::ops::function::FnOnce<(&rustc_session::session::Session, rustc_middle::ty::context::CurrentGcx, alloc::sync::Arc<rustc_data_structures::jobserver::Proxy>, &std::sync::once_lock::OnceLock<rustc_middle::ty::context::GlobalCtxt>, &rustc_data_structures::sync::worker_local::WorkerLocal<rustc_middle::arena::Arena>, &rustc_data_structures::sync::worker_local::WorkerLocal<rustc_hir::Arena>, rustc_driver_impl::run_compiler::{closure#0}::{closure#2})>>::call_once::{shim:vtable#0}
  18: rustc_interface::interface::run_compiler::<(), rustc_driver_impl::run_compiler::{closure#0}>::{closure#1}
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[Noratrieb]

(https://github.com/Noratrieb/evaluate_obligation-fingerprints/tree/e9b6576d2baa586be987876e11b07cd0bc51703a with a few patches to make it compatible with old rust)
searched nightlies: from nightly-2024-01-01 to nightly-2025-10-16
regressed nightly: nightly-2025-08-03
searched commit range: 4b55fe1...a65b04d
regressed commit: 63f6845

bisected with cargo-bisect-rustc v0.6.8

Host triple: x86_64-unknown-linux-gnu
Reproduce with:

cargo bisect-rustc --access github --start 2024-01-01 --end 2025-10-16 --preserve --script ./repro.sh 

this feels more like exposing a symptom than a root cause to me

[cyrgani]

smaller:

use std::{
    pin::Pin,
    task::{Context, Poll},
};

trait FnOnce1 {
    type Output;
}

impl<T, R> FnOnce1 for T
where
    T: FnOnce() -> R,
{
    type Output = R;
}
struct Map<F>(F);

impl<F, T> Future for Map<F>
where
    F: FnOnce1<Output = T>,
{
    type Output = T;

    fn poll(self: Pin<&mut Self>, _: &mut Context<'_>) -> Poll<T> {
        loop {}
    }
}

fn take_output<Fut: Future>(_: Pin<&mut Fut>) -> Fut::Output {
    loop {}
}

fn main() {
    let mut bazz = Map(async || ());
    let mut barr = async { Bazz {} };

    let mut _fut0 = unsafe { Pin::new_unchecked(&mut bazz) };
    let mut _fut1 = unsafe { Pin::new_unchecked(&mut barr) };
    || {
        take_output(_fut0.as_mut());
        take_output(_fut1.as_mut());
    };
}

// 1
// 2

#[derive(proc_macro_thing::MyMacro)]
#[helper]
struct Bazz {}

[Noratrieb]

Thank you very much, that was way faster than me!
You added https://github.com/rust-lang/rust/issues?q=state%3Aopen%20label%3A%22fixed-by-next-solver%22, but I'm not sure whether the next solver truly fixes the issue until it's been debugged to point at a deficiency in the old solver. The same way it might have gotten "introduced" in #144458 even though that may not be the root cause, the next solver may "fix" it while not actually fixing the root cause. I'll remove the label out of care now, it can be added again if it really is the old solvers fault.

[Noratrieb]

cc @cjgillot (i see you've already seen the issue) @compiler-errors @lcnr in case any of you is interested in this

[muja]

Thank you @Noratrieb for the further minimization! You deserve all of the credit :)

Small context:

It was a coincidence we were able to get this reproduction. The message

note: This is a known issue [...]

right under the ice was misleading, I was under the assumption that I don't have to report this and there is nothing I can do other than endure it and wait for a fix. Thankfully I was ranting on Discord when @Noratrieb clarified that a reproduction would be helpful to get this fixed.

The error message should probably be adjusted for that.