Removing cold/inline(never) from slice_error_fail causes a cycle error about rust HOT 3 CLOSED

Nightly reproducer:

#![feature(core_intrinsics)]
#![feature(const_eval_select)]
use std::intrinsics::const_eval_select;
#[inline(always)]
pub const fn f() {
    const_eval_select((), g, g)
}
#[inline(always)]
pub const fn g() {
    const_eval_select((), f, f)
}

error[E0391]: cycle detected when optimizing MIR for `f`
 --> a.rs:5:1
  |
5 | pub const fn f() {
  | ^^^^^^^^^^^^^^^^
  |
note: ...which requires optimizing MIR for `g`...
 --> a.rs:9:1
  |
9 | pub const fn g() {
  | ^^^^^^^^^^^^^^^^
  = note: ...which again requires optimizing MIR for `f`, completing the cycle

from rust.

The cycle detection probably doesn't understand const_eval_select intrinsic. The intrinsic is lowered in optimized_mir query, while cycle detection operates on promoted_mir.

from rust.

That was my instinct as well. What's tripping me up mentally is that with this patch, I can x build library without a cycle error:

diff --git a/library/core/src/str/mod.rs b/library/core/src/str/mod.rs
index 4943bbc45d0..bf5539fd1ec 100644
--- a/library/core/src/str/mod.rs
+++ b/library/core/src/str/mod.rs
@@ -80,8 +80,7 @@
 use iter::SplitInternal;
 use iter::{MatchesInternal, SplitNInternal};
 
-#[inline(never)]
-#[cold]
+#[cfg_attr(bootstrap, inline(never))]
 #[track_caller]
 #[rustc_allow_const_fn_unstable(const_eval_select)]
 #[cfg(not(feature = "panic_immediate_abort"))]

There's no remap_mir_for_const_eval_select inside of the cycle detection logic. I think there should be. But I also think that since the latest beta, we accidentally fixed this somehow?

from rust.