Clean up and speed up inference variable resolving code by jdonszelmann · Pull Request #160913 · rust-lang/rust

jdonszelmann · 2026-08-11T14:24:56Z

Clean up the resolve* family of functions in InferCtxt, renaming various functions to have more consistent and descriptive names. Adds a lot of documentation, and even wins some performance using the fact that shallow_resolve now returns root vids.

Reviewable commit by commit: some are large renames across the board, which are separated from the perf wins and small renames in other commits to hopefully make more sense.

Note

I've not used an LLM for any part of this PR, or any other PR I make. This includes any related work like research.

rustbot · 2026-08-11T14:25:00Z

changes to inspect_obligations.rs

cc @lcnr

changes to the core type system

cc @lcnr

Some changes occurred in need_type_info.rs

cc @lcnr

Some changes occurred to the core trait solver

cc @rust-lang/initiative-trait-system-refactor

changes to the core type system

cc @lcnr

jdonszelmann · 2026-08-11T14:25:09Z

@bors try @rust-timer queue

Clean up and speed up resolving code

jdonszelmann · 2026-08-11T14:53:08Z

-        match self.inner.borrow_mut().type_variables().probe(vid) {
-            TypeVariableValue::Known { value } => Ok(value),
+        match value {
+            TypeVariableValue::Known { value } => Ok(self.shallow_resolve_non_recursive(value)),


this method (and the one below) now also does the recursive resolving shallow_resolve already did. No tests change here.

View changes since the review

jdonszelmann · 2026-08-11T14:53:33Z

+    // Cold because the case in which a tyvar resolves to an intvar which resolves to a type is
+    // quite rare. It's way more common for `shallow_resolve_non_recursive` to return ty.
+    #[cold]
+    fn shallow_resolve_infer_non_recursive(&self, infer: InferTy, ty: Ty<'tcx>) -> Ty<'tcx> {


the non-recursive caase helps ~0.5% on local benchmarks. Not much, but still a bit.

View changes since the review

jdonszelmann · 2026-08-11T14:57:58Z

            }

            ty::Infer(ty::IntVar(vid)) => {
-                let nt = self.infcx.unwrap().opportunistic_resolve_int_var(vid);


renames all the opportunistic_* functions with simply shallow_resolve_*. I've done this in many places. I've added a lot of docs to all the resolve methods, which I think makes it super clear that resolving is always an opportunistic process that doesn't necessarily resolve all variables, simply because it can't always.

From the perspective of a new contributor, they'll see a resolve_* function for the first time, go to its docs, and learn that the purpose of all resolve_* methods is to opportunistically resolve variables.

Since the behavior is the same for all the resolve_* functions I think that will actually make things clearer than randomly calling some of them "opportunistic" even when the others are inherently also opportunistic.

View changes since the review

jdonszelmann · 2026-08-11T14:59:06Z

+    /// In cases where we do, this can aid performance.
    #[inline(always)]
-    fn shallow_resolve_ty_var(&self, v: TyVid, ty: Ty<'tcx>) -> Ty<'tcx> {
+    fn shallow_resolve_ty_var_with_ty(&self, v: TyVid, ty: Option<Ty<'tcx>>) -> Ty<'tcx> {


By taking an Option here, we can merge more methods' implementations. Doing this has 0 performance overhead, #[inline(always)] makes sure the callsites that always call with Some get optimized properly.

View changes since the review

could we instead change this function to not take a ty and return and Option instead?

rust-bors · 2026-08-11T15:25:32Z

💔 Test for 7e8d4ec failed: CI. Failed job:

try - dist-x86_64-linux-quick (web logs, enhanced plaintext logs)

jdonszelmann · 2026-08-11T15:47:37Z

@bors try (failed due to missing rustdoc changes now applied)

rust-bors · 2026-08-11T15:47:41Z

Unknown argument "(failed". Did you mean to use @bors jobs=<jobs>|parent=<parent>? Run @bors help or go to https://bors.rust-lang.org/help to see available commands.

panstromek · 2026-08-11T16:49:37Z

@bors try

Clean up and speed up resolving code

rust-bors · 2026-08-11T17:49:20Z

☀️ Try build successful (CI)
Build commit: d881e22 (d881e228b79422918a125ef8385170091369309b)
Base parent: a04c7a0 (a04c7a037d59b6dedc9f921e84e391f13a257aa4)

rust-timer · 2026-08-11T18:37:34Z

Finished benchmarking commit (d881e22): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

@bors rollup=never rustc-perf
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.2%	[-0.4%, -0.1%]	34
Improvements ✅ (secondary)	-0.5%	[-1.2%, -0.2%]	39
All ❌✅ (primary)	-0.2%	[-0.4%, -0.1%]	34

Max RSS (memory usage)

Results (primary 5.7%, secondary -0.7%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	5.7%	[5.1%, 6.3%]	2
Regressions ❌ (secondary)	0.6%	[0.6%, 0.6%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.8%	[-3.0%, -0.4%]	10
All ❌✅ (primary)	5.7%	[5.1%, 6.3%]	2

Cycles

Results (primary 2.5%, secondary 0.4%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.5%	[2.5%, 2.5%]	1
Regressions ❌ (secondary)	0.8%	[0.4%, 1.5%]	8
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.9%	[-1.6%, -0.5%]	3
All ❌✅ (primary)	2.5%	[2.5%, 2.5%]	1

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 463.191s -> 456.07s (-1.54%)
Artifact size: 396.43 MiB -> 396.43 MiB (-0.00%)

jdonszelmann · 2026-08-11T23:37:54Z

that seems worth it :3

… tyvar.

…er a shallow_resolve

rustbot · 2026-08-12T08:04:44Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

jdonszelmann · 2026-08-12T08:06:52Z

@rustbot review

lcnr · 2026-08-12T09:46:48Z

-                Ty::new_int_var(self.tcx, inner.int_unification_table().find(vid))
-            }
-        }
+    pub fn shallow_resolve_int_var(&self, vid: ty::IntVid) -> Ty<'tcx> {


if we return None if the inner function doesn't make progress, could we always be explicit about reconstructing the type in the caller to make it explicit where we (likely unnecessarily) do so?

View changes since the review

lcnr · 2026-08-12T09:47:29Z

                .borrow_mut()
                .unwrap_region_constraints()
-                .opportunistic_resolve_var(canonicalizer.tcx, vid);
+                .shallow_resolve_region_var(canonicalizer.tcx, vid);


we don't reuse r here if the root doesn't change 🤔 feels like doing so would be good for perf 🤔

View changes since the review

lcnr · 2026-08-12T09:52:06Z

so we have the following now

shallow_resolve_X now
deep_resolve_non_region_vars
eagerly_resolve_vars deep resolve which does resolve region vars
fully_resolve deep resolve which uses the region graph instead of only the unification tables

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver) labels Aug 11, 2026

rustbot assigned lcnr Aug 11, 2026