Code change:
The specified method, EventsPoll::new looks like: might be related with the static mut?, but haven't tried to replicate it on a smaller example, will report back if i do so
cc Would be good to find out if this was caused by , and to find an MCVE, so: ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Imma try to bisect this, it's as good an opportunity as any to learn about it!
here's a minimal example that is self-contained and shows the issue:
Bisect shows the ICE was introduced between the nightlies of the 26th (no ICE) and the 27th (ICE is present). My pc is trying to find the particular commit still, but if that takes too long (like if it has to compile (I have no idea, this is my first time bisecting)) I'll leave it to people with beefier computers :3 That said, I think you can at least rest assured-ish because our PR was merged on the 29th (according to Github).
Minimized a bit further:
Wait, bisect just finished. :laughing: searched nightlies: from nightly-2020-04-26 to nightly-2020-04-28 regressed nightly: nightly-2020-04-27 searched commits: from to regressed commit: source code: Please give the steps for how to build your repository (platform, system dependencies, etc.) <details<summaryCOLLAPSIBLE ERROR STACKTRACE</summary<p</p</details
(working on the stack trace)
Use the  tool, which fetches the artifacts generated by when testing a PR. Your CPU will be way happier :D
Yaaas that's precisely what I used. It's sooooo goooooood :sparkles:
(I haven't been able to minimize since my last comment, so I think it is now minimal)
Awesome. I'll bisect again with that one. For now, I've the full backtrace taken from today's nightly to the bisect report. Do you know how I can compile using a specific rustc's commit? (I just did and used , which used today's nightly.
Now we know which PR regressed (). It's a rollup of multiple PRs, so we'll need to guess which one is the culprit using the power of deduction :D Here I'm pretty sure this has been caused by , cc
Kay, I'll leave it to Oli then. He knows way more than I do about static initialization soundness :D also, it's (apparently) his PR. I've done one last test: did bisect with your minimal counterexample, which ICE'd on the same commit. I've edited the bisection report to have your and its backtrace :3
I cannot tell if you are being facetious here, but there is the option of bisecting over the individual PR's in the rollup itself, e.g. via directly on a local rust checkout. It is unfortunate that we don't have a way to do that mechanically within itself (which would be a huge undertaking)
From some local testing, I can confirm that reverting from fixes the ICE. cc
yeah I think posted PR which essentially reverted by moving the check elsewhere (so that we still get the fix that was trying to land). Its just waiting review; I looked at it briefly but I'm not an expert on that code so I'm going to wait for to look at it.
Right, that sentence was unclear, sorry about that. I just wrote something quickly, to tell that they didn't need to bisect every PR in the rollup, that would have been a waste of time.
it's completely fine! I got your friendly tone when you posted it. The was very helpful in that regard :rainbow: :slightlysmilingface:

Related discussion:
text: <ins> // check-pass // This is a regression test for ICEs from // https://github.com/rust-lang/rust/issues/71612 // and // https://github.com/rust-lang/rust/issues/71709 #[derive(Copy, Clone)] pub struct Glfw; static mut GLFW: Option<Glfw> = None; pub fn new() -> Glfw { unsafe { if let Some(glfw) = GLFW { return glfw; } else { todo!() } }; } extern "C" { static _dispatch_queue_attr_concurrent: [u8; 0]; } static DISPATCH_QUEUE_CONCURRENT: &'static [u8; 0] = unsafe { &_dispatch_queue_attr_concurrent }; fn main() { *DISPATCH_QUEUE_CONCURRENT; new(); } </ins>