encountered incremental compilation error with `evaluate_obligation`

[bnjbvr]

Hi! Sorry I don't really have the time to make a minimal example, but here are some steps that allow me to repro this bug with 100% rate, even after a cargo clean (@lqd told me it's worth filing a bug for this).

Code

• Clone https://github.com/bnjbvr/matrix-rust-sdk/tree/bnjbvr/send-q-reactions
• Checkout 6611815d4ebfe5d32dc230ae0aeb13ca0f9e9dfe (the commit named "WIP")
• from the main directory, run cargo nextest run --workspace --retries 0 --exclude matrix-sdk-integration-testing. (All tests should pass, but I suspect it's not required to even run them.)
• then checkout the head "WIP squared" aka 222dcc9620d33c81333dd91bdcfaabf0e5a84a33
• retry to run the above command

Meta

rustc --version --verbose:

rustc 1.80.1 (3f5fd8dd4 2024-08-06)
binary: rustc
commit-hash: 3f5fd8dd41153bc5fdca9427e9e05be2c767ba23
commit-date: 2024-08-06
host: x86_64-unknown-linux-gnu
release: 1.80.1
LLVM version: 18.1.7

Error output

Backtrace

``` error: internal compiler error: encountered incremental compilation error with evaluate_obligation(6bb4efc4e83b8d71-9f343aba19e9c9eb) | = help: This is a known issue with the compiler. Run `cargo clean -p matrix_sdk_ffi` 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 for more information thread 'rustc' panicked at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/compiler/rustc_query_system/src/query/plumbing.rs:726:9: Found unstable fingerprints for evaluate_obligation(6bb4efc4e83b8d71-9f343aba19e9c9eb): Err(Canonical) stack backtrace: 0: rust_begin_unwind at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library/std/src/panicking.rs:652:5 1: core::panicking::panic_fmt at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library/core/src/panicking.rs:72:14 2: rustc_query_system::query::plumbing::incremental_verify_ich_failed:: 3: rustc_query_system::query::plumbing::try_execute_query::>, rustc_middle::query::erase::Erased<[u8; 2]>>, false, false, false>, rustc_query_impl::plumbing::QueryCtxt, true> 4: ::process_obligation 5: >::process_obligations:: 6: >::assumed_wf_types_and_report_errors 7: rustc_hir_analysis::check::wfcheck::check_well_formed [... omitted 1 frame ...] 8: rustc_hir_analysis::check::wfcheck::check_mod_type_wf [... omitted 1 frame ...] 9: rustc_hir_analysis::check_crate 10: rustc_interface::passes::analysis [... omitted 1 frame ...] 11: 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. 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: rustc 1.80.1 (3f5fd8dd4 2024-08-06) running on x86_64-unknown-linux-gnu note: compiler flags: -C embed-bitcode=no -C linker=clang -C incremental=[REDACTED] -C strip=debuginfo -C link-arg=-fuse-ld=/usr/bin/mold note: some of the compiler flags provided by cargo are hidden query stack during panic: #0 [evaluate_obligation] evaluating trait selection obligation `timeline::Timeline: core::marker::Sync` #1 [check_well_formed] checking that `timeline::` is well-formed #2 [check_mod_type_wf] checking that types are well-formed in module `timeline` #3 [analysis] running analysis passes on this crate end of query stack ```

[pacak]

This sequence of commands avoids using of third party tools (nextest), running tests and also cuts down number of compiled crates from 800ish to 500ish

git clone https://github.com/bnjbvr/matrix-rust-sdk
git checkout 6611815d4ebfe5d32dc230ae0aeb13ca0f9e9dfe
cargo build -p matrix-sdk-ffi --tests
git checkout 222dcc9620d33c81333dd91bdcfaabf0e5a84a33
cargo build -p matrix-sdk-ffi --tests

[lukas-code]

Reduced (at least I hope that this is the same issue):

#![recursion_limit = "4"]

struct Wrapper<T>(T);

struct Foo1(Wrapper<()>);
struct Foo2(Wrapper<Wrapper<()>>);

fn send<T: Send>() {}

fn main() {
    #[cfg(not(after))]
    send::<Foo1>();
    send::<Foo2>();
}

rustc foo.rs -C incremental=incremental
rustc foo.rs -C incremental=incremental --cfg after

In the first compilation, the compiler will first check Foo1: Send and then check Foo2: Send. Here, the recursion limit will not be exceeded on the second check, because Wrapper<()>: Send was cached from the first check.

Then, in the second compilation, the compiler expects Foo2: Send to also hold, because the definitions of Foo2 and Send have not changed, but this time the check actually causes an overflow error, because Wrapper<()>: Send isn't cached and we therefore exceed the recursion limit.

@rustbot label -E-needs-mcve S-has-mcve

[lqd]

We probably have open issues that the caching scheme and overflow can result in incremental instability. I guess the good news is that this case seems to work in the new solver.

We should probably add this MCVE as a crashes test, or a check-pass incremental new solver test.