Change:
match *destination { Some((ref dest, _target_block)) => { let dest_ty = dest.ty(body, tcx).ty; <ins> let dest_ty = self.normalize(dest_ty, term_location); </ins> let category = match *dest { Place { base: PlaceBase::Local(RETURN_PLACE),

Discussion:
While experimenting with some code I hit this ICE. Interestingly, when running a second time, it magically works - skipping the error. Also, works fine too. I'm on a slightly older nightly because some rustup components are missing on the latest. confirms the ICE in both its stable and nightly.
Slight reduction:
Marking P-high. The fact that works and a regular compile does not suggests a missing call to somewhere, which would be fairly easy to fix once it is found.
Not sure if it is related but I'm writing a parser combinator library (quite similar to nom 5.0), and when I'm not getting the error described above, I'm getting another with one of my test cases. This requires me to boost the to as suggested after a few iterations 12,792,521 and the builds are getting unusually slow. A common factor for these issues is that always works. Does the compiler not like combinators? I'm not ready to release this code yet and I haven't reduced the second issue like the first. Example depth of these combinators, can obviously get deeper. Along these lines. All functions but the second arguments to return functions. (snippet of IRCv3 message-tags extension)
HA. Okay this gets more weird. Moving out to a test, everything else works except... Rust suddenly forgets how to make trivial equivalences. as above with stripped into . . Due to the requirement of a second compilation unit, I cannot reproduce this one on the playground. Oh and this one doesn't get to "just work" with miri.
Workaround. Passes the ICE and the type mismatch. Still requires in my real tests.
Using and . Without the workaround. The IRC test builds in 8.54s on the first pass (ICE) plus 2.8s on the second (no ICE). . With the workaround. The test builds in 8.49s. . The first and third both spend 61% of the time (5 seconds) on , followed by with 11-12% of the time (~980ms). The second pass to the first flips these but they're still at the top with 33% (920ms) and 31% (857ms) respectively. All other tests (much simpler) compile immediately.

Edit: No idea why the first even built in the second pass as it should have failed with the type mismatch issue... shrugs*
triage: assigning to self for investigation.
(haven't had a chance yet to look at this.)
Thanks !
Context: I was helping reduce a different (but similar) ICE from the same project and I started wondering how the reduction in this issue didn't trigger that ICE as well. Closures appear to be irrelevant, and I've reduced the testcase further to: In particular it appears that returning some type that includes is necessary for reproduction, as it leads to a vs mismatch in the caller. However, this is not the end of the story - attempting to reduce the testcase further results in other ICEs, not fixed by . The smallest such change to the above snippet is: which results in this (spanless) ICE before and after : That ICE persists through further reduction, and this is my best so far: This looks suspiciously simple, I'm surprised more people haven't hit it yet.
question I might attempt to pose at the T-compiler meeting: In cases like this, is it best to reopen the same bug when you find a variant that tickles a similar ICE? Or are we better off opening a fresh ticket for the variant code? On the one hand, a proliferation of tickets is not fun. On the other hand, it becomes pretty difficult to track what an issue number represents when you have to interpret phrases like "fixes PR #NNN" as time-relative (i.e. was that phrase written before or after the bug was reopened with a new variant example)...
I haven't had a chance to look at 's new variant yet. I will try to find time to do so, either tomorrow or next week.
Part of the reason I feel like this issue should be reopened was because I started from the same codebase got this issue's example from. Had that code been published, even to a temporary git branch, it could've been possible to check before marking this issue as fixed, if the actual code got fixed. OTOH, even if it's in the same area, I think it's technically a separate ICE, just one that got dropped accidentally from the first reduction, so I wouldn't mind a new issue either way. (And this time would be good to share the code that is triggering all of these ICEs)
Oh.

The code isn't secret just not ready to publish given the ICE issues and poor compilation performance. The directory contains the first reduction. Safe to ignore that, the main crate is the real code.
Just to clarify: it looks to me like the bug exposed from the original crate (linked above) is exercised by running , not just (which runs successfully for me). (And, as previously mentioned, you currently need to or otherwise remove the incremental compilation state, in between calls; otherwise you will fall into
I went ahead and filed to track that bug independently of this one.
marked with E-needs-mcve since it would be good to factor a minimal test out from the test suite of the
I don't understand, is just that. Or do you mean a minimal test while still using the library? (IME, that's also tricky, not all combinators can trigger an ICE)
ah sorry, at the time when you posted that comment, the source for omnon was not yet linked here, so I was unaware it had been derived from the test suite for that crate
Yeah, all the code snippets from (including the original testcase of this issue) are derived from the crate.
Okay so based on feedback it sounds like we have our MCVE
since we have our MCVE (and it seems to approximately match the test I in PR ), and I have independently filed , we can reclose this as fixed.