Change:
this.expr_as_place(block, &this.thir[value], mutability, fake_borrow_temps) }) } <del> ExprKind::Field { lhs, name } => { let place_builder = unpack!( block = this.expr_as_place(block, &this.thir[lhs], mutability, fake_borrow_temps,) ); </del> <ins> ExprKind::Field { lhs, variant_index, name } => { let lhs = &this.thir[lhs]; let mut place_builder = unpack!(block = this.expr_as_place(block, lhs, mutability, fake_borrow_temps,)); if let ty::Adt(adt_def, _) = lhs.ty.kind() { if adt_def.is_enum() { place_builder = place_builder.downcast(*adt_def, variant_index); } } </ins> block.and(place_builder.field(name, expr.ty)) } ExprKind::Deref { arg } => {

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --There's only so much that I can share. The code that seems to be erroring is similar to <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I've discovered that destructuring the enum variant outside of the async block fixes the issue
Minimal repro:
amazing that you did reduce your testcase like that. I removed the external dependecy to tokio and silenced the unused warning: Regressed in rollup probably in searched nightlies: from nightly-2021-12-01 to nightly-2022-04-24 regressed nightly: nightly-2021-12-06 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Reduced a bit more (requires an edition with precise captures, I think):
Looks like a duplicate of and
These started ICEing in (), with looking very likely.
If no one is yet investigating this, I'd like to pick it up
So far, I've found 2 issues that cause this behaviour. The first is that it's having trouble in this context to get the field type of the single variant enum: Fix is easy, The second issue is that the MIR is being badly formed. Looking at the traces, I see Which hints to me that the code is not being read as but instead
Yeah, it looks like constructed MIR is incorrect. One issue seems to be in , towards the end it has to rebase projections on top of a capture. First it has to remove the captured prefix, and the implementation makes the assumption that the number of projections in HIR and MIR will coincide. In the HIR downcasting is part of field projection, in the MIR those are two separate elements.

Thus we are left with an extra incorrect projection. There seems to be one more issue when constructing the capture - the downcasting operation is completely missing. While the documentation for MIR claims that I think that is an outdated information.
I also just noticed the Downcast issue. In my traces, I do see the variant projection using this Downcast for just a single variant, and the suspect PR changes does seem to ignore all Downcast projections (there's a little bit of discussion taking place on zulip https://rust-)
Should the fix be Downcast and truncation the capture correctly the single variant capture not use Downcast
or might be in a better position to give advice here. I think we should keep and / or add downcast where they are currently missing (e.g., when constructing the closure), and fix how projections corresponding to captured prefix are removed. As far the latter aspect is concerned, I think the issue is in the following lines ( are HIR projections which combine field and downcast into one operation, while are MIR projection elements where those two operations are separate):
I vaguely recall we relied on this to detect if we had a multi variant enum, in which case we would completely capture the root variable. Edit: Ignore that, scrolling into the code bit more, there is comment that Downcast can be expected for single-variant enums
are you still planning to work on this issue?
Not currently, I spent a few full days looking but I don't want to risk burning out debugging something that I don't completely understand . I hope I at least narrowed it down a bit

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --Notes: Replacing with `` fixes the problem Removing the closure fixes the problem <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Is this still reproducible?
Yes, unfortunately, the problem persists with this setup:
Ok, it looks like this is actually an incremental compilation issue which only appears with --edition=2021, very interesting :smile: EDIT: actually it only needs edition=2021 and is unrelated to incremental compilation :upsidedownface:
Probably a duplicate of I'll prioritize since this is just normal looking code that causes broken mir and is reproducible on stable , beta and nightly.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium

I was messing around with the crate and an ICE was raised when I tried to pattern match an enum in the function parameter. I narrowed it down to trying to pattern match a variable that exists outside the scope from within a closure. Playground link: Present in all three channels, beta, nightly and stable. Only present on 2021 edition. : <details<summary<strongBacktrace</strong</summary<p</p</details
I'm willing to work on it if it turns out to be a simple fix, hints are appreciated!
Does this still crash on nightly? I was not able to repro with
It does here, same code as above. But the backtrace has changed. <details<summaryBacktrace</summary</details
Ah I missed the :upsidedownface: :+1: