Change:
<ins> error[E0282]: type annotations needed --> $DIR/issue-112225-2.rs:13:9 | LL |     let x = Default::default(); |         ^ ... LL |         async { x.0; }, |                 - type must be known at this point | help: consider giving `x` an explicit type | LL |     let x: /* Type */ = Default::default(); |          ++++++++++++ error: aborting due to previous error For more information about this error, try `rustc --explain E0282`. </ins>

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --My code does not compile any more after updating to 1.70.0. The project can be found I tried to create a minimal reproducer. It has something to do with glib's clone macro, which I use. Here is the reproducer that compiles fine on 1.69 but not on 1.70.0. I left some comments in the code describing what I observed so far. It needs and dependency): Output I expected to see this happen: The type is correctly inferred Instead, this happened: The compiler tells me that it doesn't know the type, although the type can be inferred <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.69.0 <!-- Provide the version you are using that has the regression. --:
regressed in cc slightly minimized and removed dependencies: Putting the identity function back (or wrapping the async block in a block) seems to "fix" the error: <details<summarybisector output</summarysearched nightlies: from nightly-2023-03-01 to nightly-2023-06-01 regressed nightly: nightly-2023-03-15 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details</details label -regression-untriaged +regression-from-stable-to-stable +A-inference +A-async-await
It is not only an identity function that makes this suddenly work, but putting the async block in a block works as well. Permuting what to wrap in a block, only a single case out of the four fails: Out of curiousity I tried the patch in thats supposed to fix to make async blocks "provide inference guidance", but that doesn’t work either.
This happens due to a hack in typeck, where function arguments that aren't closures, including block expressions that return closures, are typechecked before function parameters that are closures.

Note that async blocks are desugared to closures. This basically means that closures and async blocks in function arguments behave as if they were ordered after all non-closure non-async-block arguments and you now get the same inference error that you would get on older compilers if you manually swapped the function arguments. (Also, looks like this hack has existed .)
Wow, that is a very good catch! And also good news, as it means "fixing" the regression should be a oneliner, which I will try tomorrow. However that does smell like a very gross hack, and I wonder if there will eventually be a better way altogether. But that is for a different day.
Note that just excluding desugared async block closures from this hack breaks inference for different programs that are now accepted on stable, for example:
you mean which are only accepted as of 1.70?
Yeah, I mean stable 1.70. But I guess it's better to break a constructed program that compiled for one stable version instead of breaking a real codebase that compiled for several stable versions.
I'd be fine landing a PR that excludes future-desugared async blocks from this hack.
I opened with a fix and regression test. Thanks so much for finding the code responsible for this, I sure would have gone crazy with this :-D As both the culprit PR and the 1.70 beta went through a crater run, we are wondering why this was never caught earlier? Is it correct to assume your code exhibiting this problem is closed source? Or is it in some public repo that is not yet scraped by crater?
My code is GPLv3 and can be found on GitHub. I've never heard of and I don't think it is scraped. But it would really cool if it could scrape my project, too. To actually build it, you also need some system libraries installed like glib2, gtk4, libadwaita, etc. No idea whether can handle this special case.
Crater should automatically pick up any public Rust project on github. But I’m not an expert on it by any means. Its quite possible that it ignores certain crates that depend on specific system libraries.
Your repo is on crater under the name "symphony", but it's failing to build due to outdated system libraries. <details<summarycrater log</summary</details
WG-prioritization assigning priority ().

label -I-prioritize +P-high Note: unsure if we wanted to keep issues open when the fix is nominated for a backport