Implement custom awaitable support #78071

333fred · 2025-04-08T22:34:44Z

This adds support for awaiting task-like types that are not natively supported by runtime async. Closes #77897.

Recommend reviewing each commit separately; the first commit is a new BoundNode helper for side-effects in lowering as part of an expression. The second commit is the actual implementation of custom awaitable support, using that helper.

Relates to test plan #75960

This adds support for awaiting task-like types that are not natively supported by runtime async. Closes dotnet#77897.

src/Compilers/CSharp/Portable/Lowering/AsyncRewriter/RuntimeAsyncRewriter.cs

jcouv

Done with review pass (iteration 3). Haven't looked at new bound node logic and tests yet

This reverts commit c265a64.

jcouv

Code looks good. Will look at tests Monday

src/Compilers/CSharp/Test/Emit/CodeGen/CodeGenAsyncTests.cs

src/Compilers/CSharp/Portable/Lowering/AsyncRewriter/RuntimeAsyncRewriter.cs

cston · 2025-04-22T03:38:54Z

src/Compilers/CSharp/Portable/Lowering/AsyncRewriter/RuntimeAsyncRewriter.cs

+
+        var awaitableInfo = node.AwaitableInfo;
+        var awaitablePlaceholder = awaitableInfo.AwaitableInstancePlaceholder;
+        if (awaitablePlaceholder is not null)


When is awaitablePlaceholder == null? (If it is null, it looks like we'll not execute expr.) Consider asserting instead of using if.

I was basing it off the similar handling in the existing async rewriter, but I believe you're correct, this should never be null.

Actually, it can be null. See https://github.com/dotnet/roslyn/blob/main/src/Compilers/CSharp/Portable/Binder/UsingStatementBinder.cs#L153-L154. It appears to only be the case when we're dealing with dynamic, which is already covered under the prototype comment above.

src/Compilers/CSharp/Test/Emit/CodeGen/CodeGenAsyncTests.cs

…ustom-awaiters * upstream/features/runtime-async: (3563 commits) Disable failing Test1 and Test5 lines (dotnet#78118) Update ignored directives public API (dotnet#77968) Expression trees: support optional arguments and named arguments in parameter order (dotnet#77972) Update resourceManagement.yml (dotnet#77948) Split query execution into compile and execute calls (dotnet#78081) Remove unused ISemanticSearchWorkspaceHost (dotnet#78083) Add back EA.Razor for servicing branches Remove EditorFeatures from OOP (dotnet#78069) Review feedback Fix nullability warnings Do not return metadata names for document symbols Improve detection of code whose updates may not have effect (dotnet#78009) Ensure LSP uses actual signature help trigger characters Update RoslynAnalyzer package projects with dependencies Simplify analyzer api Unseal LSP types (dotnet#78041) Compile just for NET Fix name Docs Move type ...

* Handle basic await scenarios (#76121) Add initial handling of expressions that return `Task`, `Task<T>`, `ValueTask`, `ValueTask<T>`. * Add RuntimeAsyncMethodGenerationAttribute (#77543) Adds control for whether to use runtime async. The flowchart is as follows: 1. The flag `System.Runtime.CompilerServices.RuntimeFeature.Async` must be present. 2. Assuming that flag is present, we look for the presence of `System.Runtime.CompilerServices.RuntimeAsyncMethodGenerationAttribute` on the method. If that attribute is present, we use the preference expressed in the attribute. The preference does not carry to nested contexts, such as local functions or lambdas. 3. If the attribute is not present, we look for `features:runtime-async=on` on the command line. If that is present, then the feature is on by default. Otherwise, the feature is off. * Semantic search info * Implement custom awaitable support (#78071) This adds support for awaiting task-like types that are not natively supported by runtime async. Closes #77897. * Move runtime async method validation into initial binding (#78310) We now do method construction and validation for runtime async helpers up front in initial binding, rather than doing it in `RuntimeAsyncRewriter`. I've also renamed the APIs as per dotnet/runtime#114310 (comment) (though I haven't added ConfigureAwait support yet, that will be the next PR). We now validate: * The helpers come from `System.Runtime.CompilerServices.AsyncHelpers`, defined in corelib. This means that I now need a fairly extensive corelib mock to be able to compile. When we have a testing runtime that defines these helpers, we can remove the giant mock and use the real one. * We properly error when expected helpers aren't present. * We properly check to make sure that constraints are satisfied when doing generic substitution in one of the runtime helpers. * Runtime async is not turned on if the async method does not return `Task`, `Task<T>`, `ValueTask`, or `ValueTask<T>`. Relates to test plan #75960 * React to main changes #78246 and #78231. * Switch MethodImplAttributes.Async to 0x2000 (#78536) It was changed in dotnet/runtime#114310 as 0x400 is a thing in framework. * Ensure return local is the correct type for runtime async (#78603) * Add test demonstrating current behavior * Ensure return local is the correct type in async scenarios * Ensure method is actually async when doing local rewrite * Exception Handler support (#78773) * Update EH tests to run with runtime async * Handle non-null exception filter prologues in the spill sequencer * Add more testing to show current incorrect behavior * Unskip ConditionalFacts that do not need to be skipped. * Handle ensuring that the method remains valid, even when there is an `await` in a finally section. Add signifcant testing of `await using`. * Fix baselines * Support `await foreach` and add runtime async verification to existing tests. * Remove unnecessary generic * Failing tests, add async void test suggestion * CI failures * Add additional test * Test fixes * Remove implemented PROTOTYPE, add assertion on behavior. * Update to SpillSequenceSpiller after some more debugging and tightening the assertion * Fix nullref * Enable nullable for VisitCatchBlock * Support using a simple overload resolution for finding Await helpers from the BCL (#79135) * Support using a simple overload resolution for finding Await helpers from the BCL This PR removes special knowledge of what `Await` helpers correspond to what types, and instead implements a very simple form of overload resolution. We immediately bail on any conflict or error and fall back to attempting to use `AwaitAwaiter` or `UnsafeAwaitAwaiter` when such scenarios are detected. I've also updated the rules to better reflect what is actually implementable. * Create the full BoundCall in initial binding. * PR feedback. * Baseline struct lifting tests (#79505) * Extract expectedOutput constants, minor touchups * Rename expected -> expectedOutput * Include new testing with placeholder baselines * Progress * First ILVerify pass * Initial baseline IL run. * Further baseline additions and skips based on missing corelib apis. * Clone async void tests and have them use async Task, and validate existing code spit for these under runtime async * Update baselines after .NET 10 intake * Delete the stub * Remove long dynamic baseline and leave a prototype. * Feedback. * BOM * Remove unused references parameter * Block `await dynamic` * Block hoisted variables from runtime async for now * Update test baselines for block * Block arglist in runtime async * Add IL baseline * Handle an additional branch beyond the end of the method case. * Move prototype comments to issues. * Remove entry point prototypes * Add assert and comment * Add back assert * Report obsolete/experimental diagnostics on await helpers. * Fix ref safety analysis build error. --------- Signed-off-by: Emmanuel Ferdman <[email protected]> Co-authored-by: Jan Jones <[email protected]> Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com> Co-authored-by: Cyrus Najmabadi <[email protected]> Co-authored-by: David Barbet <[email protected]> Co-authored-by: Ankita Khera <[email protected]> Co-authored-by: David Wengier <[email protected]> Co-authored-by: Rikki Gibson <[email protected]> Co-authored-by: Cyrus Najmabadi <[email protected]> Co-authored-by: Rikki Gibson <[email protected]> Co-authored-by: akhera99 <[email protected]> Co-authored-by: Joey Robichaud <[email protected]> Co-authored-by: Todd Grunke <[email protected]> Co-authored-by: Youssef1313 <[email protected]> Co-authored-by: Joey Robichaud <[email protected]> Co-authored-by: Tomáš Matoušek <[email protected]> Co-authored-by: Amadeusz Wieczorek <[email protected]> Co-authored-by: Charles Stoner <[email protected]> Co-authored-by: Jared Parsons <[email protected]> Co-authored-by: Sam Harwell <[email protected]> Co-authored-by: dotnet-maestro[bot] <42748379+dotnet-maestro[bot]@users.noreply.github.com> Co-authored-by: Jason Malinowski <[email protected]> Co-authored-by: Etienne Baudoux <[email protected]> Co-authored-by: AlekseyTs <[email protected]> Co-authored-by: Jan Jones <[email protected]> Co-authored-by: Maryam Ariyan <[email protected]> Co-authored-by: Andrew Hall <[email protected]> Co-authored-by: Arun Chander <[email protected]> Co-authored-by: Kauwai Lucchesi <[email protected]> Co-authored-by: Bill Wagner <[email protected]> Co-authored-by: PaddiM8 <[email protected]> Co-authored-by: Matteo Prosperi <[email protected]> Co-authored-by: Julien Couvreur <[email protected]> Co-authored-by: Matteo Prosperi <[email protected]> Co-authored-by: Carlos Sánchez López <[email protected]> Co-authored-by: Tomas Matousek <[email protected]> Co-authored-by: Deepak Rathore (ALLYIS INC) <[email protected]> Co-authored-by: Emmanuel Ferdman <[email protected]> Co-authored-by: Evgeny Tvorun <[email protected]> Co-authored-by: Victor Pogor <[email protected]> Co-authored-by: Ella Hathaway <[email protected]> Co-authored-by: Viktor Hofer <[email protected]> Co-authored-by: Jason Malinowski <[email protected]> Co-authored-by: DoctorKrolic <[email protected]> Co-authored-by: John Douglas Leitch <[email protected]> Co-authored-by: Matt Thalman <[email protected]> Co-authored-by: Bernd Baumanns <[email protected]> Co-authored-by: Thomas Shephard <[email protected]> Co-authored-by: DoctorKrolic <[email protected]> Co-authored-by: David Barbet <[email protected]> Co-authored-by: Chris Sienkiewicz <[email protected]> Co-authored-by: tmat <[email protected]> Co-authored-by: [email protected] <[email protected]> Co-authored-by: Gen Lu <[email protected]> Co-authored-by: Oleg Tkachenko <[email protected]> Co-authored-by: Matt Mitchell <[email protected]> Co-authored-by: Djuradj Kurepa <[email protected]> Co-authored-by: Copilot <[email protected]> Co-authored-by: Stuart Lang <[email protected]> Co-authored-by: RaymondY <[email protected]> Co-authored-by: Gobind Singh <[email protected]> Co-authored-by: David Kean <[email protected]>

333fred added 2 commits March 31, 2025 16:21

Add BoundLoweredConditionalSideEffect for use in rewriting

c265a64

Implement custom awaitable support

e37bcc2

This adds support for awaiting task-like types that are not natively supported by runtime async. Closes dotnet#77897.

333fred requested a review from a team as a code owner April 8, 2025 22:34

ghost added Area-Compilers untriaged Issues and PRs which have not yet been triaged by a lead labels Apr 8, 2025

333fred added Feature - Runtime Async and removed Area-Compilers untriaged Issues and PRs which have not yet been triaged by a lead labels Apr 8, 2025

333fred requested review from RikkiGibson and jcouv April 8, 2025 22:34

jcouv self-assigned this Apr 9, 2025

jcouv added the Area-Compilers label Apr 9, 2025