Change:
) -> Result<&'tcx LayoutDetails, LayoutError<'tcx>> { use SavedLocalEligibility::*; let tcx = self.tcx; <del> let recompute_memory_index = |offsets: &[Size]| -> Vec<u32> { debug!("recompute_memory_index({:?})", offsets); let mut inverse_index = (0..offsets.len() as u32).collect::<Vec<_>>(); inverse_index.sort_unstable_by_key(|i| offsets[*i as usize]); let mut index = vec![0; offsets.len()]; for i in 0..index.len() { index[inverse_index[i] as usize] = i as u32; } debug!("recompute_memory_index() => {:?}", index); index }; </del> let subst_field = |ty: Ty<'tcx>| { ty.subst(tcx, substs.substs) }; let info = tcx.generator_layout(def_id);

Discussion:
Unfortunately the error message is super thin and I can't provide the source of the project. Therefore it's also hard to provide a minimal reproducible example. Some hints: Yesterdays nightly (nightly-2019-06-11-x8664-apple-darwin) doesn't ICE The project makes heavy use of async/await. Therefore it might by related to that. I wondered whether it's about generator optimization from . However I also checked that out locally from their branch 2 days ago and built it myself, and it didn't crash. At that point I had all commits up to "Extract generatorlayout as a method" included, only the last commit which was later was missing.
Could you please test your code out with in (you'll need to build rustc yourself) and provide the more extensive backtrace?
I tried running that over the afternoon. Unfortunately something went wrong: Unfortunately that happened after around 1.5 hours of compilation. This machine here is definitely too slow for doing any reasonable rustc compilation :'(
Got it running by deleting enough libraries and rebuilding. Unfortunately it just prints exactly the same error message. I think the setting might already had been enabled as far as I can derive from the compiler output above:
I played around with my code and deleted stuff until I got a simple repro: It seems like the combination of the member function together with the closure parameter might be the culprit. A top level or a a "static" member function (without ) doesn't cause an ICE. This also crashes if is not an async function and thereby no is included at all:
Reduction of version: Reduction of non- version:
Note that you only need to get the backtrace ( is much more expensive). Maybe we even have builds with that enabled nowadays? Not sure though. EDIT: also, someone needs to do this on linux, the backtraces are probably broken on macOS.
triage: leaving unprioritized; assigning to with intent that they attach priority label as well as any Async-Await specific labels. Leaving nomination tag but hoping I'll remember to skip over it at this week's meeting.
Hi, any temporally way to check on this? My build for tests (just build, just tests) have been failed for days and I have no idea which part of my code caused this in a large code base.
I also see this in my project.

I built my own compiler with enabled for now, In case anyone is interested, this is what I get when building the non- version :
I've been investigating, and I believe this is caused by a subtle bug in . (EDIT: In short, we weren't listing ZST fields at the beginning of the layout anymore.) The reason didn't reproduce in their checkout of the branch is likely that the bug didn't show up until one of the last changes I made to the branch, responding to final review feedback before merging. Working on a fix and will have it up soon with more details.
Opened .