Optimize handling of solver errors by ChayimFriedman2 · Pull Request #160160 · rust-lang/rust

ChayimFriedman2 · 2026-07-29T15:23:36Z

Check for the empty case in collect_remaining_errors().
Instead of representing trait errors as Vec<Error>, use a special type

This has multiple advantages:
- Performance. The new type is 1/3 the size of Vec (being equivalent in layout to Option<ThinVec>) and can be kept in a register.
- Type safety. We mark the type #[must_use], and thinks requiring errors take ThinVec, which requires unwrapping the type and verifying there is indeed an error. We still provide conversions to slices, ThinVec, and iteration, because some code needs this and I saw no benefit in changing it, but we deliberately do not provide Deref<Target = [E]> or things like that.

ChayimFriedman2 · 2026-07-29T15:23:41Z

Check for the empty case in `collect_remaining_errors()`

panstromek · 2026-07-29T15:39:02Z


    fn collect_remaining_errors(&mut self, infcx: &InferCtxt<'tcx>) -> Vec<E> {
-        #[allow(clippy::iter_skip_zero)]
+        if self.obligations.pending.is_empty() && self.obligations.overflowed.is_empty() {
+            // In 99.983% this is true, so this helps perf.
+            return Vec::new();
+        }
+
        self.obligations


One other thing I'd try later too is that sometimes it helps is to put #[inline] on the function and wrap the rest of the code after the fast path in outline(move || { ... })).

View changes since the review

True, I also wanted to check if making this ThinVec will help since it will return in a register. It may cancel with outlining though.

ChayimFriedman2 · 2026-07-29T15:48:00Z

@bors cancel

rust-bors · 2026-07-29T15:48:03Z

❗ There is currently no auto build in progress on this PR.

Hint: There is a pending try build on this PR. Maybe you meant to cancel it? You can do that using @bors try cancel.

ChayimFriedman2 · 2026-07-29T15:48:14Z

@bors try cancel

rust-bors · 2026-07-29T15:48:18Z

Try build cancelled. Cancelled workflows:

https://github.com/rust-lang/rust/actions/runs/30465642688

ChayimFriedman2 · 2026-07-29T15:53:20Z

@bors try @rust-timer queue

Check for the empty case in `collect_remaining_errors()`

the8472 · 2026-07-29T15:58:01Z

I think it's worth checking this in std's TrustedLen specializations. The code is querying the size-hint anyway, it might as well bail early rather than invoking the next machinery.

ChayimFriedman2 · 2026-07-29T15:59:52Z

It might be interesting, but std's specialization applies to much more diverse range of behaviors. There we can't know if "empty most of the times" is the common case.

rust-bors · 2026-07-29T17:59:18Z

☀️ Try build successful (CI)
Build commit: f5bcd01 (f5bcd011d3725a90befeaac099c3fe9d56706db8)
Base parent: d366396 (d3663963ca08f465d01d283a7199778902623bb9)

rust-timer · 2026-07-29T19:31:57Z

Finished benchmarking commit (f5bcd01): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking means the PR may be perf-sensitive. Consider adding rollup=never if this change is not fit for rolling up.

@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
Improvements ✅ (secondary)	-1.6%	[-3.6%, -0.2%]	3
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary -3.6%, 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)	-	-	0
Regressions ❌ (secondary)	0.7%	[0.7%, 0.7%]	1
Improvements ✅ (primary)	-3.6%	[-5.5%, -1.2%]	3
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-3.6%	[-5.5%, -1.2%]	3

Cycles

Results (primary 0.4%, secondary 0.5%)

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

	mean	range	count
Regressions ❌ (primary)	0.8%	[0.5%, 1.4%]	9
Regressions ❌ (secondary)	1.6%	[0.4%, 5.2%]	13
Improvements ✅ (primary)	-1.4%	[-2.3%, -0.4%]	2
Improvements ✅ (secondary)	-1.6%	[-5.5%, -0.5%]	7
All ❌✅ (primary)	0.4%	[-2.3%, 1.4%]	11

Binary size

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

Bootstrap: 489.658s -> 489.161s (-0.10%)
Artifact size: 390.17 MiB -> 390.11 MiB (-0.01%)

ChayimFriedman2 · 2026-07-29T19:50:32Z

Okay, so not only this does not regress #160073 this also has a non-negligible improvement. Seems worth to merge, but I'll try to see if I can use ThinVec or something similar before.

panstromek · 2026-07-29T20:08:28Z

Yea, the large-workspace change is likely noise, but the other two are legit. ThinVec might help or not, because it stores len=0 in a static singleton, while Vec keeps it on a stack. Using Option<ThinVec> for the empty case can get around that (and it's the same size).

ChayimFriedman2 · 2026-07-29T20:18:14Z

Option<ThinVec> is what I'm doing (more precisely a custom enum with the same layout). But it's a slightly bigger change.

ChayimFriedman2 · 2026-07-29T21:13:16Z

@bors try @rust-timer queue

Check for the empty case in `collect_remaining_errors()`

rust-bors · 2026-07-29T23:18:19Z

☀️ Try build successful (CI)
Build commit: 79906d6 (79906d6d0a86f5d6217ccecf0a9294440b328283)
Base parent: b5be620 (b5be620d5ac9824c4a6030df9fb72644ef4f459b)

rust-timer · 2026-07-30T00:00:26Z

Finished benchmarking commit (79906d6): comparison URL.

Overall result: ❌✅ regressions and improvements - please read:

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.

Next, please: If you can, justify the regressions found in this try perf run in writing along with @rustbot label: +perf-regression-triaged. If not, fix the regressions and do another perf run. Neutral or positive results will clear the label automatically.

@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.2%	[0.2%, 0.3%]	6
Improvements ✅ (primary)	-0.3%	[-0.5%, -0.1%]	68
Improvements ✅ (secondary)	-0.5%	[-2.1%, -0.1%]	69
All ❌✅ (primary)	-0.3%	[-0.5%, -0.1%]	68

Max RSS (memory usage)

Results (primary -0.1%, secondary -0.1%)

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

	mean	range	count
Regressions ❌ (primary)	2.9%	[2.9%, 2.9%]	1
Regressions ❌ (secondary)	0.8%	[0.8%, 0.8%]	1
Improvements ✅ (primary)	-1.6%	[-2.5%, -0.6%]	2
Improvements ✅ (secondary)	-0.5%	[-0.5%, -0.4%]	3
All ❌✅ (primary)	-0.1%	[-2.5%, 2.9%]	3

Cycles

Results (primary 0.1%, 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)	1.0%	[0.4%, 2.0%]	5
Regressions ❌ (secondary)	1.5%	[0.7%, 3.0%]	5
Improvements ✅ (primary)	-0.8%	[-1.6%, -0.5%]	5
Improvements ✅ (secondary)	-0.8%	[-1.1%, -0.4%]	5
All ❌✅ (primary)	0.1%	[-1.6%, 2.0%]	10

Binary size

Results (secondary 0.0%)

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

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.0%	[0.0%, 0.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Bootstrap: 489.76s -> 487.975s (-0.36%)
Artifact size: 390.94 MiB -> 390.13 MiB (-0.21%)

ChayimFriedman2 · 2026-07-30T00:04:01Z

Improvements greatly outweigh regressions, including in non-next-solver benchmarks. Seems like this was a good idea.

rustbot · 2026-07-30T00:04:11Z

Some changes occurred in const_evaluatable.rs

cc @BoxyUwU

Some changes occurred to the core trait solver

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

clippy is developed in its own repository. If possible, consider making this change to rust-lang/rust-clippy instead.

cc @rust-lang/clippy

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

Some changes occurred in engine.rs, potentially modifying the public API of ObligationCtxt.

cc @lcnr

HIR ty lowering was modified

cc @fmease

Some changes occurred to constck

cc @fee1-dead

Some changes occurred in compiler/rustc_passes/src/check_attr.rs

cc @jdonszelmann, @JonathanBrouwer

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

rustbot · 2026-07-30T00:04:13Z

r? @TaKO8Ki

rustbot has assigned @TaKO8Ki.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: compiler, types
compiler, types expanded to 74 candidates
Random selection from 16 candidates

ChayimFriedman2 · 2026-07-30T00:04:56Z

To the reviewer: The commits are fully separate. I can create separate PRs, but the first commit is very small so I don't think it's needed.

As it's very common.

This has multiple advantages: - Performance. The new type is 1/3 the size of `Vec` (being equivalent in layout to `Option<ThinVec>`) and can be kept in a register. - Type safety. We mark the type `#[must_use]`, and thinks requiring errors take `ThinVec`, which requires unwrapping the type and verifying there is indeed an error. We still provide conversions to slices, `ThinVec`, and iteration, because some code needs this and I saw no benefit in changing it, but we deliberately do not provide `Deref<Target = [E]>` or things like that.