add a FCW for overflow errors with the next solver by adwinwhite · Pull Request #159224 · rust-lang/rust

adwinwhite · 2026-07-13T13:50:51Z

The old solver doesn't check cache entry's depth requirement when looking up cache while the next solver correctly does so. It's necessary to behave correctly with respect to incremental compilation.
As a result, the next solver is more likely to run into overflow errors.

We try to catch such breakages by rerun the evaluation with doubled recursion limit and if that succeeds we emit a FCW.

This PR is being discussed on zulip

The lint issue is #159228

r? @lcnr

adwinwhite · 2026-07-13T13:51:18Z

@bors try @rust-timer queue

[WIP] add FCW for overflow with the next solver

rust-bors · 2026-07-13T15:58:27Z

☀️ Try build successful (CI)
Build commit: 6eb68d9 (6eb68d9057fb9a60e047c7c7dcc9b67b9cedc1a7)
Base parent: 5503df8 (5503df87342a73d0c29126a7e08dc9c1255c46ad)

rust-timer · 2026-07-13T16:39:33Z

Finished benchmarking commit (6eb68d9): comparison URL.

Overall result: ❌ regressions - 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)	2.3%	[0.3%, 4.5%]	9
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary -2.1%, secondary -0.9%)

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)	1.4%	[0.8%, 2.5%]	3
Improvements ✅ (primary)	-2.1%	[-2.1%, -2.1%]	1
Improvements ✅ (secondary)	-4.5%	[-4.7%, -4.3%]	2
All ❌✅ (primary)	-2.1%	[-2.1%, -2.1%]	1

Cycles

Results (secondary -4.2%)

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
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.2%	[-5.7%, -2.7%]	2
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 487.42s -> 490.943s (0.72%)
Artifact size: 389.91 MiB -> 389.35 MiB (-0.15%)

lcnr

The impl itself looks good to me 🤔 though I do really want to move the reevaluation out of evaluate_root_goal[_for_proof_tree] even if you need to have separate methods for root and proof tree.

I think this compat hack is non-trivial and having it be self-contained with a comment explaining why and what we do here feels very valuable for people looking at this while trying to understand how the trait solver works.

View changes since this review

lcnr · 2026-07-23T09:36:41Z

                .placeholder_assumptions_for_next_solver
                .clone(),
            next_trait_solver: self.next_trait_solver,
+            disable_next_solver_overflow_fcw: self.disable_next_solver_overflow_fcw,


change the flag to "enable_next_solver_overflow_fcw" negated booleans are always somewhat meh imo !disable_next_solver_overflow_fcw is harder to parse than !enable_next_solver_overflow_fcw

View changes since the review

lcnr · 2026-07-23T09:40:55Z

+    /// The `recursion_depth_exceeding_limit` lint detects situations where the obligation evaluation
+    /// overflows with the next solver but not with the old solver.
+    ///
+    /// ### Example
+    /// ```text
+    /// rustc -Znext-solver example.rs
+    /// ```
+    ///
+    /// ```rust,ignore (requires next solver)
+    /// #![recursion_limit = "8"]
+    /// struct Foo<T> {
+    ///    t: T,
+    ///    opt_t: Option<T>,
+    /// }
+    /// fn require_sync<T: Sync>() {}
+    /// fn main() {
+    ///     require_sync::<Foo<Foo<Foo<Foo<Foo<Foo<()>>>>>>>();
+    /// }
+    /// ```
+    ///
+    /// This will produces:
+    /// ```text
+    /// error[E0275]: overflow evaluating the requirement `Foo<Foo<Foo<Foo<Foo<Foo<()>>>>>>: Sync`
+    ///  --> example.rs:12:20
+    ///   |
+    ///   |     require_sync::<Foo<Foo<Foo<Foo<Foo<Foo<()>>>>>>>();
+    ///   |                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+    ///   |
+    ///   = help: consider increasing the recursion limit by adding a `#![recursion_limit = "16"]` attribute to your crate
+    /// note: required by a bound in `require_sync`
+    ///  --> example.rs:9:20
+    ///   |
+    ///   | fn require_sync<T: Sync>() {}
+    ///   |                    ^^^^ required by this bound in `require_sync`
+    /// ```
+    ///
+    /// ### Explanation
+    ///
+    /// The trait solvers use a recursion limit to avoid hangs from deeply nested obligations.
+    /// They also use caches to avoid redundant computation. This is a performance optimization and
+    /// shouldn't affect the final evaluation result.
+    ///
+    /// However, the old solver doesn't validate depth requirement when looking up cache. This means
+    /// evaluation results depend on whether cache entries exists which in turn depends on cache
+    /// insertion order.
+    ///
+    /// The next solver correctly records and validates recursion depth requirements when using
+    /// the cache. This makes it more prone to overflow compared to the old solver.
+    ///
+    /// This is a [future-incompatible] lint to transition this to a hard error in the future.


similar to the lint name, we should not tell the user about implementation details here.

I think the focus should be "this lint detects cases where we previously did not correctly track the recursion depth"

I would now say that it happens in "obligation evaluation" and would put the explanation that this is because of the "new solver" to later in the explanation, not in the initial summary

View changes since the review

lcnr · 2026-07-23T09:42:03Z

+{
+    // We still check coherence typing mode because we don't use the next solver in orphan check
+    // by default yet and orphan check uses `TypingMode::Coherence`.
+    if delegate.disable_next_solver_overflow_fcw() || delegate.typing_mode_raw().is_coherence() {


don't need an || here as we can just set the flag in coherence?

View changes since the review

lcnr · 2026-07-23T09:53:41Z

r=me after nits

rustbot · 2026-07-24T02:46:39Z

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.

adwinwhite · 2026-07-24T05:09:04Z

@bors r=lcnr

rust-bors · 2026-07-24T05:09:08Z

📌 Commit 203ebf2 has been approved by lcnr

It is now in the queue for this repository.

@lcnr

add a FCW for overflow errors with the next solver The old solver doesn't check cache entry's depth requirement when looking up cache while the next solver correctly does so. It's necessary to behave correctly with respect to incremental compilation. As a result, the next solver is more likely to run into overflow errors. We try to catch such breakages by rerun the evaluation with doubled recursion limit and if that succeeds we emit a FCW. This PR is being discussed on [zulip](https://rust-lang.zulipchat.com/#narrow/channel/364551-t-types.2Ftrait-system-refactor/topic/The.20old.20solver.20don.27t.20record.20required.20depth.20on.20cache/with/604756008) The lint issue is #159228 r? @lcnr

rust-bors · 2026-07-24T09:17:51Z

💔 Test for 61842aa failed: CI. Failed job:

auto - x86_64-mingw-1 (web logs, enhanced plaintext logs)

rust-log-analyzer · 2026-07-24T09:28:50Z

A job failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

jhpratt · 2026-07-24T10:29:19Z

@bors retry