Change:
} impl<'tcx> UpvarSubsts<'tcx> { <ins> /// Returns an iterator over the list of types of captured paths by the closure/generator. /// In case there was a type error in figuring out the types of the captured path, an /// empty iterator is returned. </ins> #[inline] pub fn upvar_tys(self) -> impl Iterator<Item = Ty<'tcx>> + 'tcx { <del> let tupled_upvars_ty = match self { UpvarSubsts::Closure(substs) => substs.as_closure().split().tupled_upvars_ty, UpvarSubsts::Generator(substs) => substs.as_generator().split().tupled_upvars_ty, </del> <ins> let tupled_tys = match self { UpvarSubsts::Closure(substs) => substs.as_closure().tupled_upvars_ty(), UpvarSubsts::Generator(substs) => substs.as_generator().tupled_upvars_ty(), </ins> }; <del> tupled_upvars_ty.expect_ty().tuple_fields() </del> <ins> match tupled_tys.kind() { TyKind::Error(_) => None, TyKind::Tuple(..) => Some(self.tupled_upvars_ty().tuple_fields()), TyKind::Infer(_) => bug!("upvar_tys called before capture types are inferred"), ty => bug!("Unexpected representation of upvar types tuple {:?}", ty), } .into_iter() .flatten() </ins> } #[inline]

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. --edit: I reduced some code of a different occurrence and came up with <!-- 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. --I bisected the regression to / <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Reduced code from another project that also triggers this ICE: `
Cargo-bisetc-rustc points to /
cc and
The error on stable is So it's a case of error-ICE.
After some trying I found out that this will panic for every keyword, that is followed by an unexpected token, in an async function, that returns
Assigning and removing as in the prioritization working group.
I can also reproduce the ICE with the following code:
After investigation, I think I have found the cause of the bug. When we get to the contained in is a , because of the invalid or or any wrong syntax. Then we call which expects a so it panics.
Unless someone gets to it before, but I can get a fix in by if not over the weekend. Though from what I understand about that code it shouldn't be TyKind::Error, it should be Infer/Tuple. interesting...
Potential fix in
A possible duplicate.
Fix in (in progress)
The third time's the charm. More future proof solution:
I was just about to open a new issue when I saw this and it looks like it has been fixed—but since I already typed it out and it might provide further info, here it is: <!-- 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. --or No ICE when: just the return value is omitted just the args are omitted both the return value and args are omitted is replaced with <!-- 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.

--: No ICE on <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I hit a similiar bug... As it is already known and fixed, I won't post a new bug report, but as I already have it, here is my data point: I don't have a minimal example, I just know that I got an error on the following git checkout: <!-- 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. --: The following command triggered the ICE: <details<summary<strongBacktrace</strong</summary<p</p</details