revert mir inlining policy for beta-1.64

compiler/rustc_mir_transform/src/inline.rs

@@ -9,7 +9,6 @@ use rustc_middle::mir::visit::*;
 use rustc_middle::mir::*;
 use rustc_middle::ty::subst::Subst;
 use rustc_middle::ty::{self, ConstKind, Instance, InstanceDef, ParamEnv, Ty, TyCtxt};
-use rustc_session::config::OptLevel;
 use rustc_span::{hygiene::ExpnKind, ExpnData, LocalExpnId, Span};
 use rustc_target::spec::abi::Abi;
 
@@ -44,15 +43,8 @@ impl<'tcx> MirPass<'tcx> for Inline {
             return enabled;
         }
 
-        match sess.mir_opt_level() {
-            0 | 1 => false,
-            2 => {
-                (sess.opts.optimize == OptLevel::Default
-                    || sess.opts.optimize == OptLevel::Aggressive)
-                    && sess.opts.incremental == None
-            }
-            _ => true,
-        }
+        // rust-lang/rust#101004: reverted to old inlining decision logic
+        sess.mir_opt_level() >= 3
     }
 
     fn run_pass(&self, tcx: TyCtxt<'tcx>, body: &mut Body<'tcx>) {

src/test/codegen/mem-replace-direct-memcpy.rs

@@ -1,3 +1,15 @@
+// ignore-test
+
+// WHY IS THIS TEST BEING IGNORED:
+//
+// This test depends on characteristics of how the stdlib was compiled,
+// namely that sufficient inlining occurred to ensure that the call to
+// `std::mem::replace` boils down to just two calls of `llvm.memcpy`.
+//
+// But the MIR inlining policy is in flux as of 1.64-beta, and the intermittent
+// breakage of this test that results is causing problems for people trying to
+// do development.
+
 // This test ensures that `mem::replace::<T>` only ever calls `@llvm.memcpy`
 // with `size_of::<T>()` as the size, and never goes through any wrapper that
 // may e.g. multiply `size_of::<T>()` with a variable "count" (which is only

src/test/ui/issues/issue-100550-normalization-ice-exposed-by-mir-inlining.rs

@@ -0,0 +1,39 @@
+// check-pass
+
+// compile-flags: --emit=mir,link -O
+
+// There is an ICE somewhere in type normalization, and we are hitting it during
+// the MIR inlining pass on this code.
+//
+// Long term, we should fix that ICE and change the compile-flags for this test
+// to explicitly enable MIR inlining.
+//
+// Short term, we are diabling MIR inlining for Rust 1.64-beta, so that we avoid
+// this ICE in this instance.
+
+pub trait Trait {
+    type Associated;
+}
+impl<T> Trait for T {
+    type Associated = T;
+}
+
+pub struct Struct<T>(<T as Trait>::Associated);
+
+pub fn foo<T>() -> Struct<T>
+where
+    T: Trait,
+{
+    bar()
+}
+
+#[inline]
+fn bar<T>() -> Struct<T> {
+    Struct(baz())
+}
+
+fn baz<T>() -> T {
+    unimplemented!()
+}
+
+fn main() { }

src/test/ui/mir/issue-100476-recursion-check-blewup.rs

@@ -0,0 +1,42 @@
+// check-pass
+
+// compile-flags: --emit=mir,link -O
+
+// At one point the MIR inlining, when guarding against infinitely (or even just
+// excessive) recursion, was using `ty::Instance` as the basis for its history
+// check. The problem is that when you have polymorphic recursion, you can have
+// distinct instances of the same code (because you're inlining the same code
+// with differing substitutions), causing the amount of inlining to blow up
+// exponentially.
+//
+// This test illustrates an example of that filed in issue rust#100476.
+
+#![allow(unconditional_recursion)]
+#![feature(decl_macro)]
+
+macro emit($($m:ident)*) {$(
+    // Randomize `def_path_hash` by defining them under a module with
+    // different names
+    pub mod $m {
+    pub trait Tr {
+        type Next: Tr;
+    }
+
+    pub fn hoge<const N: usize, T: Tr>() {
+        inner::<N, T>();
+    }
+
+    #[inline(always)]
+    fn inner<const N: usize, T: Tr>() {
+        inner::<N, T::Next>();
+    }
+    }
+)*}
+
+// Increase the chance of triggering the bug
+emit!(
+    m00 m01 m02 m03 m04 m05 m06 m07 m08 m09
+    m10 m11 m12 m13 m14 m15 m16 m17 m18 m19
+);
+
+fn main() { }