Change:
<ins> // build-pass // compile-flags: -Zmir-opt-level=3 use std::fmt::Debug; use std::mem::ManuallyDrop; use std::ptr; pub trait BitRegister {} macro_rules! register { ($($t:ty),+ $(,)?) => { $( impl BitRegister for $t { } )* }; } register!(u8, u16, u32); pub trait BitStore: Sized + Debug { /// The register type that the implementor describes. type Mem: BitRegister + Into<Self>; } macro_rules! store { ($($t:ty),+ $(,)?) => { $( impl BitStore for $t { type Mem = Self; } )+ }; } store!(u8, u16, u32,); #[repr(C)] pub struct BitVec<T> where T: BitStore, { /// Region pointer describing the live portion of the owned buffer. pointer: ptr::NonNull<T>, /// Allocated capacity, in elements `T`, of the owned buffer. capacity: usize, } impl<T> BitVec<T> where T: BitStore, { pub fn new() -> Self { let pointer = ptr::NonNull::<T>::new(ptr::null_mut()).unwrap(); BitVec { pointer, capacity: 10 } } pub fn clear(&mut self) { unsafe { self.set_len(0); } } #[inline] pub unsafe fn set_len(&mut self, new_len: usize) {} fn with_vec<F, R>(&mut self, func: F) -> R where F: FnOnce(&mut ManuallyDrop<Vec<T::Mem>>) -> R, { let cap = self.capacity; let elts = 10; let mut vec = ManuallyDrop::new(unsafe { Vec::from_raw_parts(ptr::null_mut(), elts, cap) }); let out = func(&mut vec); out } } impl<T> Drop for BitVec<T> where T: BitStore, { #[inline] fn drop(&mut self) { //  The buffer elements do not have destructors. self.clear(); //  Run the `Vec` destructor to deällocate the buffer. self.with_vec(|vec| unsafe { ManuallyDrop::drop(vec) }); } } fn main() { let bitvec = BitVec::<u32>::new(); } </ins>

Discussion:
I found this ICE while compiling in release mode. : <details<summary<strongBacktrace</strong</summary<p</p</detailsbisect command: bisect result: Regression in
uuh cc
For repro:
You're right that this ICEs after my PR but not before, but this looks like an issue related to type system code or , not MIR inlining itself, so I don't think I can't help here.
Ah so it would have iced before if we had forced inlining before?
Yes, with enough application of this code should ICE before that PR. I couldn't tell you where to apply the attribute though, just squinting at the ICE message it looks like this is significant, though I don't know enough to track down where that closure is.
Is there some rustc flag I can use to force inlining of like ~ everything ~ for testing purposes? :eyes: edit: -Zinline-mir-threshold=0 or something like that? :D
You need to set both thresholds, and I don't think we have a magic value for "always", just use a big number. The defaults are 50 and 100 I think. Also just FYI there's also an inlining depth limit that's not configurable, but it shouldn't be relevant for this PR. But if you see unexpected missed inlinings even with passing those flags, that threshold might be why.
Oh, those flags won't help you before the PR in question, because functions without are simply not considered for inlining at all, no matter their size. Fixing this odd ignoring of size was the whole point of that PR. You can pass to lift that "must have " requirement, but of course that turns on other passes, but the check you're trying to dodge is an explicit check for the MIR opt level inside the Inline pass so... yeah just you might also hit other bugs. You could try turning off the passes that are enabled at mir-opt-level=3 but that would be messy.

The mir opt level is cranked up already anyway Maybe I can find some snippet that somehow reassembles what we are seeing here :) I'll be able to report back in an hour or so I guess ^^
Meh besides a couple more "hangs" (process timeouts) nothing new in the standard rustc test set :/
This is a dupe of I believe
Another reproducer (possibly large): Run in , with rustc 1.71.0-nightly ( 2023-04-29) running on x86_64-unknown-linux-gnu. Failing CI log:
I've been getting this too since about a month ago: I can do a bisect.