Open compiler-errors opened 3 months ago
Related issue: #127306
There's also a similar issue when checking whether there are duplicate method names.
trait SomeTrait {}
struct Thing<T>(T);
impl<T> Thing<T> where T: SomeTrait {
fn foo(&self) {}
}
impl<T> Thing<T> {
fn bar(&self) where T: SomeTrait {}
}
struct Dummy;
impl Thing<Dummy> {
fn foo(&self) {} // compiles
fn bar(&self) {} // errors
}
Given:
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 https://github.com/rust-lang/rust/issues/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.