From 950437a035aa81cf2af3d8aebdf8d9b294c54395 Mon Sep 17 00:00:00 2001
From: Ben Kimock <kimockb@gmail.com>
Date: Wed, 28 Aug 2024 19:36:46 -0400
Subject: [PATCH] Use a reduced recursion limit in the MIR inliner's cycle
breaker
---
compiler/rustc_mir_transform/src/inline/cycle.rs | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/compiler/rustc_mir_transform/src/inline/cycle.rs b/compiler/rustc_mir_transform/src/inline/cycle.rs
index 56e8905bead3c..c65cc993b19fd 100644
--- a/compiler/rustc_mir_transform/src/inline/cycle.rs
+++ b/compiler/rustc_mir_transform/src/inline/cycle.rs
@@ -135,6 +135,14 @@ pub(crate) fn mir_callgraph_reachable<'tcx>(
}
false
}
+ // FIXME(-Znext-solver): Remove this hack when trait solver overflow can return an error.
+ // In code like that pointed out in #128887, the type complexity we ask the solver to deal with
+ // grows as we recurse into the call graph. If we use the same recursion limit here and in the
+ // solver, the solver hits the limit first and emits a fatal error. But if we use a reduced
+ // limit, we will hit the limit first and give up on looking for inlining. And in any case,
+ // the default recursion limits are quite generous for us. If we need to recurse 64 times
+ // into the call graph, we're probably not going to find any useful MIR inlining.
+ let recursion_limit = tcx.recursion_limit() / 2;
process(
tcx,
param_env,
@@ -143,7 +151,7 @@ pub(crate) fn mir_callgraph_reachable<'tcx>(
&mut Vec::new(),
&mut FxHashSet::default(),
&mut FxHashMap::default(),
- tcx.recursion_limit(),
+ recursion_limit,
)
}