Change:
self.set_tainted_by_errors(); let tcx = self.tcx; <ins> // Precompute the provided types and spans, since that's all we typically need for below let provided_arg_tys: IndexVec<ProvidedIdx, (Ty<'tcx>, Span)> = provided_args .iter() .map(|expr| { let ty = self .typeck_results .borrow() .expr_ty_adjusted_opt(*expr) .unwrap_or_else(|| tcx.ty_error()); (self.resolve_vars_if_possible(ty), expr.span) }) .collect(); </ins> // A "softer" version of the `demand_compatible`, which checks types without persisting them, // and treats error types differently // This will allow us to "probe" for other argument orders that would likely have been correct

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. --Found this one while researching for , probably has a related cause (since diagnostics call a second time which confuses the compiler). This is an ICE though so opening a dedicated issue. cc searched nightlies: from nightly-2022-04-10 to nightly-2022-05-09 regressed nightly: nightly-2022-04-17 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: : </details<!-- 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
This does not ICE on stable 1.62.0 but ICEs on Beta version: 1.63.0-beta.3 (2022-07-02 ) and Nightly version: 1.64.0-nightly (2022-07-03 )
label regression-from-stable-to-nightly
I think this should actually be label +regression-from-stable-to-beta
Sorry label -regression-from-stable-to-nightly
WG-prioritization assigning priority (). label -I-prioritize +P-medium

This perfectly wrong statement causes compiler to mention s, and even though nothing like this is written in the code: (here and after normal errors about argument number/type mismatch are not shown as they are not the problem) Originally I've found this while editing some async code and passing instead of . I was very confused and thought that it somehow relates to //etc but after some minification I was left with the snippet above. This error becomes less confusing after desugaring loop by hand: Note that using is required to trigger this bug, using doesn't trigger it for some reason. In fact, you don't even need a : So in the end, this can be triggered with an / one of branches on which is diverging expression with that is being passed to a function with wrong number of arguments. As I previously said, I've found this while working on async code and I think this is the main way how this error can be seen (let's be serious, nobody calls functions with loop arguments). The reason why it's easier to find this error with async is that blocks are commonly passed to functions (like ) and can contain loops inside them. In my case the code looked something like this: Which caused an error like this: ! Note that "expected because of this" points to the last statement in the block even though it has nothing to do, really, with the error. searched nightlies: from nightly-2022-04-10 to nightly-2022-05-09 regressed nightly: nightly-2022-04-17 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: : : </detailsBisection shows that this issue was introduced by which aligns with other observations. This is likely caused by the same underlying problem as : diagnostic code calls a second time which confuses different parts of the compiler. cc as they've worked on fixing issues caused by before This is reproducible with (2022-07-02 ) and with most nightly-es after (except for those that ICE).

label +A-diagnostics +D-confusing +D-incorrect <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I wonder if this is also fixed by -- I will check and/or fix this too. claim