Compiler hangs and consumes unbounded memory with complex trait bounds

[i1i1]

I tried this code:

trait TraitWithOneGeneric<P> {
    fn method(&self);
}

impl<C, P1, P2> TraitWithOneGeneric<(P1, P2)> for C
where
    C: TraitWithOneGeneric<P1> + TraitWithOneGeneric<P2>,
{
    fn method(&self) {}
}

// Generic instead of impl trait also doesn't work
fn do_smth<P>(a: &&impl TraitWithOneGeneric<P>) {
    a.method(1, 2, 3, 4)
}

I expected to see this happen: Code should throw an error and rustc should exit (or compile)

Instead, this happened: rustc doesn't exit at all and leaks memory infinitely.

Meta

I ran this code either on rust playground or via rustc --crate-type rlib -v lib.rs

rustc --version --verbose:

rustc 1.81.0-nightly (6b0f4b5ec 2024-06-24)
binary: rustc
commit-hash: 6b0f4b5ec3aa707ecaa78230722117324a4ce23c
commit-date: 2024-06-24
host: x86_64-unknown-linux-gnu
release: 1.81.0-nightly
LLVM version: 18.1.7

Same behavior on stable:
rustc --version --verbose:

rustc 1.79.0 (129f3b996 2024-06-10)
binary: rustc
commit-hash: 129f3b9964af4d4a709d1383930ade12dfe7c081
commit-date: 2024-06-10
host: x86_64-unknown-linux-gnu
release: 1.79.0
LLVM version: 18.1.7

[matthiaskrgr]

Might be a duplicate of #80066

[i1i1]

Maybe you're right, but perf top tells that it spends 55-70% of the time in this function:

rust/compiler/rustc_trait_selection/src/traits/fulfill.rs

Line 307 in d929a42

fn process_obligation(

[lqd]

as expected in a lot of these cases of hangs: @rustbot label +fixed-by-next-solver

[saethlin]

This is not a leak. It is very different to leak memory and have unbounded data structure growth or unbounded recursion, which is what's happening here.

[workingjubilee]

the eventual stabilization PR for next-solver is gonna fix like half of the open issues for rust-lang/rust at this rate.

[i1i1]

Just in case, I've tried rustc with -Znext-solver and it shows the following error:

error[E0275]: overflow evaluating the requirement `&impl TraitWithOneGeneric<P>: TraitWithOneGeneric<_>`
  --> lib.rs:16:7
   |
16 |     a.method()
   |       ^^^^^^

While if I do this: (*a).method() everything works perfectly (even without next-solver)