Given:

use core::ops::Deref;

struct W<T>(T);
struct X;

impl<T> Deref for W<T> {
    type Target = X;
    fn deref(&self) -> &Self::Target { &X }
}

trait A {}
trait B {}

impl<T: A> W<T> {
    fn a(&self) {} // EXAMPLE A
}
impl<T> W<T> {
    fn b(&self) where T: B {}  // EXAMPLE B
}

impl X {
    fn a(&self) {}
    fn b(&self) {}
}

fn main() {
    let w = W(());
    w.a(); // Works.
    w.b(); // Doesn't work.
}

I expected this code to work. Whether I place the where clause on the impl block (like in example A) or on the method (like in example B) should not matter.

Method probing should assemble the method's "own" where clauses so we can use them. This would've prevented the regression in #129601, since #129449 rearranged some where clause bounds for readability.

Let's not actually fix this until the new solver has landed, since it's likely to cause spurious new overflows in practice, which are fatal. In the new solver, it should be fine 👍

We could technically support this in the old solver, if we were to filter out any predicates that mention the method's generics. But this seems to be a hack that I'd need convincing is worthwhile rather than waiting to do it the "right" way...

There's also theoretically more places for incompleteness to guide inference on the args, but I expect that to not be an issue TBH, since we already (afaict) process obligations before/while doing argument checking.