Do not compute type_of for impl item if impl where clauses are unsatisfied

[compiler-errors]

Consider the following code:

traitFoo{fncall(self) -> implSend;}traitNested{}impl<T>FooforTwhereT:Nested,{fncall(self) -> implSized{NotSatisfied.call()}}structNotSatisfied;implFooforNotSatisfied{fncall(self) -> implSized{todo!()}}

In impl Foo for NotSatisfied, we need to prove that the RPITIT is well formed. This requires proving the item bound <NotSatisfied as Foo>::RPITIT: Send. Normalizing <NotSatisfied as Foo>::RPITIT: Send assembles two impl candidates, via the NotSatisfied impl and the blanket T impl. We end up computing the type_of for the blanket impl even if NotSatisfied: Nested where clause does not hold.

This type_of query ends up needing to prove that its own impl Sized RPIT satisfies Send, which ends up needing to compute the hidden type of the RPIT, which is equal to the return type of NotSatisfied.call(). That ends up in a query cycle, since we subsequently try normalizing that return type via the blanket impl again!

In the old solver, we don't end up computing the type_of an impl candidate if its where clauses don't hold, since this select call would fail before confirming the projection candidate:

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

Line 882 in d7ea436

let impl_source = match selcx.select(&trait_obligation){

This PR makes the new solver more consistent with the old solver by adding a call to try_evaluate_added_goals after regstering the impl predicates, which causes us to bail before computing the type_of for impls if the impl definitely doesn't apply.

r? lcnr

Fixesrust-lang/trait-system-refactor-initiative#185

[lcnr]

r=me on the fix. I think there's no good reason not to call try_evaluate_goals here.

I also feel like it sucks that we need to think about these cycles in the first place :< #139788

[lcnr]

@bors r+ rollup

[bors]

📌 Commit 105d1dc has been approved by lcnr

It is now in the queue for this repository.