Implement "low priority impls" by WaffleLapkin · Pull Request #159003 · rust-lang/rust

WaffleLapkin · 2026-07-09T09:58:36Z

lcnr · 2026-07-13T08:55:16Z

+        // On new solver `obligations_referencing_infer_var` calls `resolve_vars_if_possible`,
+        // which can lead to inference progress. Use a probe so that this doesn't leak...


that feels quite odd 🤔

why do you need the probe/what's the problem if we do leak inference progress here?

View changes since the review

Removing this make some tests fail (on the branch that uses #[rustc_low_priority_impl] for impl<T> From<!> for T):

failures: [ui] tests/ui/traits/next-solver/cycles/coinduction/fixpoint-exponential-growth.rs [ui] tests/ui/traits/next-solver/cycles/inductive-fixpoint-hang.rs [ui] tests/ui/traits/next-solver/cycles/coinduction/item-bound-via-impl-where-clause.rs#next [ui] tests/ui/traits/next-solver/cycles/cycle-modulo-ambig-aliases.rs [ui] tests/ui/traits/next-solver/overflow/exponential-trait-goals.rs

With diffs like these:

diff of stderr: - error[E0275]: overflow evaluating the requirement `W<_>: Trait` + error[E0275]: overflow evaluating the requirement `W<(W<_>, W<_>)>: Trait` 2 --> $DIR/exponential-trait-goals.rs:17:13 3 | 4 LL | impls::<W<_>>();

- error[E0275]: overflow evaluating the requirement `W<_>: Trait` + error[E0275]: overflow evaluating the requirement `W<W<_>>: Trait` 2 --> $DIR/inductive-fixpoint-hang.rs:33:19 3 | 4 LL | impls_trait::<W<_>>();

10 LL | fn transmute<L: Trait<R>, R>(r: L) -> <L::Proof as Trait<R>>::Proof { r } 11 | ^^^^^^^^ required by this bound in `transmute` 12 - error[E0275]: overflow evaluating the requirement `<Vec<u8> as Trait<String>>::Proof == _` + error[E0275]: overflow evaluating the requirement `<Vec<u8> as Trait<String>>::Proof == String` 14 --> $DIR/item-bound-via-impl-where-clause.rs:31:21 15 | 16 LL | let s: String = transmute::<_, String>(vec![65_u8, 66, 67]); 17 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

lcnr · 2026-07-13T08:56:39Z

+                    let clause = obligation.predicate().as_trait_clause()?;
+                    let trait_obligation = obligation.with(self.tcx, clause);
+
+                    // `compute_applicable_impls_for_diagnostics` has a lot of side effects, put it in a probe.


what? compute_applicable_impls_for_diagnostics should use probes per candidate instead 😅

it's kind of crazy that it currently doesn't

View changes since the review

It is indeed crazy that it doesn't. Do you want me to change it in this PR/as a prerequisite?

can you split that out into a separate PR?

lcnr · 2026-07-13T08:59:35Z

+                .args
+                .iter()
+                .filter_map(|arg| arg.as_type())
+                .any(|t| self.type_matches_expected_vid(t, expected_vid, UseSubtyping::Yes)),


while not relevant for the never type blanket impl, I would prefer to instead use a type visitor which looks for the relevant infer var so that we detect T: Trait<Vec<?my_infer>>

View changes since the review

ArhanChaudhary · 2026-07-22T00:49:03Z

+    /// priority" ones, if there is exactly 1 normal priority applicabble
+    /// implementation.
+    ///
+    /// This is a [future-incompatible] lint, in the future we will remove the


Grammatical error here called a comma splice. Meow :3

View changes since the review

…y referencing error Without this change `tests/ui/async-await/async-closures/is-not-fn.rs` ICEing when constructing proof tree, supposedly to check if an infer var is referenced in a goal...

@lcnr

Type fallback refactorings - Don't merge different kinds of infer variables into `Ty` before matching them back - Do fallback only on root vars (this is semantically equivalent to what we currently do; unifying any of the infer vars from the same equivalence class necesserily affects all of them) (this makes #159003 a bit less hacky though) - Do some simplification that has been allowed by the previous changes cc @lcnr

@lcnr

Type fallback refactorings - Don't merge different kinds of infer variables into `Ty` before matching them back - Do fallback only on root vars (this is semantically equivalent to what we currently do; unifying any of the infer vars from the same equivalence class necesserily affects all of them) (this makes #159003 a bit less hacky though) - Do some simplification that has been allowed by the previous changes cc @lcnr

rust-bors · 2026-08-05T14:34:43Z

☔ The latest upstream changes (presumably #159026) made this pull request unmergeable. Please resolve the merge conflicts by rebasing.

@lcnr

Type fallback refactorings - Don't merge different kinds of infer variables into `Ty` before matching them back - Do fallback only on root vars (this is semantically equivalent to what we currently do; unifying any of the infer vars from the same equivalence class necesserily affects all of them) (this makes rust-lang/rust#159003 a bit less hacky though) - Do some simplification that has been allowed by the previous changes cc @lcnr

@lcnr

Type fallback refactorings - Don't merge different kinds of infer variables into `Ty` before matching them back - Do fallback only on root vars (this is semantically equivalent to what we currently do; unifying any of the infer vars from the same equivalence class necesserily affects all of them) (this makes rust-lang/rust#159003 a bit less hacky though) - Do some simplification that has been allowed by the previous changes cc @lcnr

@lcnr

Type fallback refactorings - Don't merge different kinds of infer variables into `Ty` before matching them back - Do fallback only on root vars (this is semantically equivalent to what we currently do; unifying any of the infer vars from the same equivalence class necesserily affects all of them) (this makes rust-lang/rust#159003 a bit less hacky though) - Do some simplification that has been allowed by the previous changes cc @lcnr

rustbot assigned lcnr Jul 9, 2026

WaffleLapkin added needs-fcp This change is insta-stable, or significant enough to need a team FCP to proceed. T-types Relevant to the types team, which will review and decide on the PR/issue. labels Jul 9, 2026