Chris Denton 0bd531aaf2 Rollup merge of #140276 - compiler-errors:typeof-less-eagerly, r=lcnr ... Do not compute type_of for impl item if impl where clauses are unsatisfied Consider the following code: ```rust trait Foo { fn call(self) -> impl Send; } trait Nested {} impl<T> Foo for T where T: Nested, { fn call(self) -> impl Sized { NotSatisfied.call() } } struct NotSatisfied; impl Foo for NotSatisfied { fn call(self) -> impl Sized { 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: d7ea436a02/compiler/rustc_trait_selection/src/traits/project.rs (L882) 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 Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/185		2025-04-28 23:29:16 +00:00
..
src	Rollup merge of #140276 - compiler-errors:typeof-less-eagerly, r=lcnr	2025-04-28 23:29:16 +00:00
Cargo.toml	norm nested aliases before evaluating the parent goal	2025-04-24 18:41:43 +00:00