From 7841fc61d206fc511d0399151e92844269ab0f90 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?R=C3=A9my=20Rakic?= Date: Sun, 1 Sep 2024 11:31:54 +0000 Subject: [PATCH] Revert "Use a reduced recursion limit in the MIR inliner's cycle breaker" This reverts commit 950437a035aa81cf2af3d8aebdf8d9b294c54395. --- compiler/rustc_mir_transform/src/inline/cycle.rs | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/compiler/rustc_mir_transform/src/inline/cycle.rs b/compiler/rustc_mir_transform/src/inline/cycle.rs index 9828e90de883e..41b9fb2edd1ce 100644 --- a/compiler/rustc_mir_transform/src/inline/cycle.rs +++ b/compiler/rustc_mir_transform/src/inline/cycle.rs @@ -136,14 +136,6 @@ 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, @@ -152,7 +144,7 @@ pub(crate) fn mir_callgraph_reachable<'tcx>( &mut Vec::new(), &mut FxHashSet::default(), &mut FxHashMap::default(), - recursion_limit, + tcx.recursion_limit(), ) }