Move runtime async method validation into initial binding #78310

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Open

333fred wants to merge 10 commits into dotnet:features/runtime-async from 333fred:initial-binding-validation

Member

333fred commented Apr 24, 2025 •

edited by jcouv

Loading

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

333fred added 9 commits

April 22, 2025 15:16


          Add AsyncHelpers as an internal special type

351c386


          Progress on moving the type definitions.

442f9f8


          Remove async feature flag

216d5c9


          Readd missing signature

ff721e5


          Move to a fully mocked corelib for testing

1f5aefc


          Rename AwaitAwaiter apis from api review

33a4423


          Move method construction and validation into initial binding, and act…

…ually perform constraint validation on generically-constructed runtime helper methods.


          Additional missing member testing

9df8371


          Small order refactor

c10918c

333fred added the Feature - Runtime Async label

333fred requested a review from a team as a code owner

April 24, 2025 23:39

dotnet-issue-labeler bot added Area-Compilers untriaged labels

333fred requested review from RikkiGibson and jcouv

April 24, 2025 23:39


          NRT warning

459f528

jcouv reviewed

View reviewed changes

src/Compilers/CSharp/Portable/Binder/Binder_Await.cs

                               out PropertySymbol? isCompleted,
                               out MethodSymbol? getResult,
                               getAwaiterGetResultCall: out _,
+                              out MethodSymbol? runtimeAsyncAwaitCall,

Member

jcouv Apr 25, 2025

runtimeAsyncAwaitCall

"runtimeAsyncAwaitMethod"? ("method" instead of "call") Also applies elsewhere

jcouv reviewed

View reviewed changes

src/Compilers/CSharp/Portable/Binder/Binder_Await.cs

+                              && GetGetResultMethod(getAwaiter, node, expression.Type!, diagnostics, out getResult, out getAwaiterGetResultCall)
+                              && (!isRuntimeAsyncEnabled || getRuntimeAwaitAwaiter(awaiterType, out runtimeAsyncAwaitCall));
+                          bool tryGetRuntimeAwaitHelper(out MethodSymbol? runtimeAwaitHelper)

Member

jcouv Apr 25, 2025

There are captures. This reduces readability and causes allocations. Consider reducing to only capture this. Same for getRuntimeAwaitAwaiter below
I'd suggest keeping the isRuntimeAsyncEnabled check at the call site (if (isRuntimeAsyncEnabled && tryGetRuntimeAwaitHelper(...)) for clarity

jcouv reviewed

View reviewed changes

src/Compilers/CSharp/Portable/Binder/Binder_Await.cs

+                              var exprOriginalType = expression.Type!.OriginalDefinition;
+                              SpecialMember awaitCall;
+                              TypeWithAnnotations? maybeNestedType = null;

Member

jcouv Apr 25, 2025

nit: "nestedType" seems strange. Consider "resultType"

jcouv reviewed

View reviewed changes

src/Compilers/CSharp/Portable/Binder/Binder_Await.cs

+                                  runtimeAwaitHelper = runtimeAwaitHelper.Construct([nestedType]);
+                                  checkMethodGenericConstraints(runtimeAwaitHelper, diagnostics, expression.Syntax.Location);
+                              }
+              #if DEBUG

Member

jcouv Apr 25, 2025

nit: do we need this directive?

jcouv reviewed

View reviewed changes

src/Compilers/CSharp/Portable/Binder/Binder_Await.cs

+                              return true;
+                          }
+                          void checkMethodGenericConstraints(MethodSymbol method, BindingDiagnosticBag diagnostics, Location location)

Member

jcouv Apr 25, 2025

Would this helper from ConstraintHelper do the job? public static bool CheckConstraints(this MethodSymbol method, in CheckConstraintsArgs args)

jcouv reviewed

View reviewed changes

src/Compilers/CSharp/Portable/BoundTree/BoundNodes.xml

    
            @@ -693,6 +693,10 @@
          
                  <Field Name="GetAwaiter" Type="BoundExpression?" Null="allow"/>

                  <Field Name="IsCompleted" Type="PropertySymbol?" Null="allow"/>

                  <Field Name="GetResult" Type="MethodSymbol?" Null="allow"/>

                  <!-- Refers to the runtime async helper we call for awaiting. Either this is an instance of an AsyncHelpers.Await call, and

Member

jcouv Apr 25, 2025

an instance of an AsyncHelpers.Await call

we're not storing a call
consider also commenting on the null case

Member

jcouv Apr 25, 2025

Consider adding a Validate method with HasValidate="true"

Member

jcouv Apr 25, 2025 •

edited

Loading

Let's take a note to revisit the GetAwaitExpressionInfo API which exposes various bits of BoundAwaitableInfo. We may also want to update NullableWalker.VisitAwaitExpression. [update:] On second thought, maybe we don't need to, as these methods are from corlib (we can afford some assumptions)
It would also be good to review the various consumers of BoundAwaitableInfo and check if some can assert that RuntimeAsyncAwaitMethod is null (for example, AsyncMethodToStateMachineRewriter.VisitAwaitExpression)

jcouv reviewed

View reviewed changes

src/Compilers/CSharp/Portable/Symbols/AssemblySymbol.cs

    
                      // Keep in sync with VB's AssemblySymbol.RuntimeSupportsAsyncMethods

                      internal bool RuntimeSupportsAsyncMethods

                          => RuntimeSupportsFeature(SpecialMember.System_Runtime_CompilerServices_RuntimeFeature__Async)

                             || _overrideRuntimeSupportsAsyncMethods;

                          => GetSpecialType(InternalSpecialType.System_Runtime_CompilerServices_AsyncHelpers) is { TypeKind: TypeKind.Class, IsStatic: true };

Member

jcouv Apr 25, 2025

Should we remove the runtime feature entry from the design doc?

jcouv reviewed

View reviewed changes

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

+                          _factory.Compilation.GetSpecialType(InternalSpecialType.System_Runtime_CompilerServices_AsyncHelpers)));
+                      Debug.Assert(runtimeAsyncAwaitMethod.Name is "Await" or "UnsafeAwaitAwaiter" or "AwaitAwaiter");
+                      if (runtimeAsyncAwaitMethod.Name == "Await")

Member

jcouv Apr 25, 2025

nit: this feels a bit weird. Would it be better to split this into two fields in BoundAwaitableInfo (one for Await case and one for AwaitAwait case)?

jcouv reviewed

View reviewed changes

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

+                              // await default(System.Threading.Tasks.ValueTask<int>);
+                              Diagnostic(ErrorCode.ERR_RefConstraintNotSatisfied, "default(System.Threading.Tasks.ValueTask<int>)").WithArguments("System.Runtime.CompilerServices.AsyncHelpers.Await<T>(System.Threading.Tasks.ValueTask<T>)", "T", "int").WithLocation(1, 7)
+                          );
+                      }

Member

jcouv Apr 25, 2025 •

edited

Loading

Consider adding a test for void-returning method showing we'll still generate a state machine.
could be in a later PR: consider adding a test for await using and await foreach in a runtime-async method
nit: should we include a test where the types are present but not from corlib?

jcouv reviewed

View reviewed changes

src/Compilers/CSharp/Portable/Compilation/CSharpCompilation.cs

+                              && !ReferenceEquals(methodReturn, GetSpecialType(InternalSpecialType.System_Threading_Tasks_ValueTask))
+                              && !ReferenceEquals(methodReturn, GetSpecialType(InternalSpecialType.System_Threading_Tasks_ValueTask_T)))
+                          {
+                              return false;

Member

jcouv Apr 25, 2025

Is there a corresponding update to the design doc? Or should we have a follow-up comment to make the void-returning method scenario work at some point?

jcouv self-assigned this

jcouv reviewed

View reviewed changes

Member

jcouv left a comment

Done with review pass (iteration 10)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Area-Compilers Feature - Runtime Async untriaged