Change:
// We can still be zero-sized in this branch, in which case we have to // return `None`. <del> if size.bytes() == 0 { // We may be reading from a static. // In order to ensure that `static FOO: Type = FOO;` causes a cycle error // instead of magically pulling *any* ZST value from the ether, we need to // actually access the referenced allocation. The caller is likely // to short-circuit on `None`, so we trigger the access here to // make sure it happens. self.get_raw(ptr.alloc_id)?; None } else { Some(ptr) } </del> <ins> if size.bytes() == 0 { None } else { Some(ptr) } </ins> } }) }

Discussion:
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:

I tried this code: Tried to build the  crate. I expected to see this happen: Successful build. Instead, this happened: Compiler panic. : rustc 1.45.0-nightly ( 2020-04-26) binary: rustc commit-hash: commit-date: 2020-04-26 host: x86_64-apple-darwin release: 1.45.0-nightly LLVM version: 9.0 Backtrace:
finds the resgression in searched nightlies: from nightly-2020-04-26 to nightly-2020-04-27 regressed nightly: nightly-2020-04-27 searched commits: from to regressed commit:
We've seen this on . It seems to apply only to when targeting Mac OS or iOS. The same nightly on Linux does not cause an ICE.
Presumably due to cc It looks iOS-specific because wraps an iOS-specific API. Would be good to find an MCVE.
Assigning as and removing .
ping cleanup Let’s try to find an MVCE and find out if this ICE only appears on MacOS.
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
Huh, curious. I guess we didn't catch it there because crater doesn't run on ios, but also the error is one I would not have expected to come from that PR. That PR should have only caused new cycle errors, nothing else.
I think I hit the same error on OSX in the crate; check .
Yeah, that's also the crate causing it
I'm seeing the same error, also caused by the dispatch crate on macOS (not iOS):
Minimal repro: