-
Notifications
You must be signed in to change notification settings - Fork 5.1k
[RuntimeAsync] Tweak some reflection scenarios around async methods. #118045
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.
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
Conversation
Tagging subscribers to this area: @mangod9 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR tweaks reflection behavior around async methods by ensuring async variant methods are not visible through reflection APIs. The changes implement a consistent approach where async variants "do not exist" in reflection since they're not present in IL, while making infrastructure helpers like AsyncHelpers.Await
visible but non-invokable through reflection.
Key changes:
- Async variant methods are filtered out from reflection queries and interface mappings
- Infrastructure async methods throw when invoked via reflection
- Tests are added to verify the new reflection behavior with async methods
Reviewed Changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated 4 comments.
Show a summary per file
File | Description |
---|---|
src/tests/async/reflection/reflection-simple.csproj | Enables the test project by adding process isolation and priority settings |
src/tests/async/reflection/reflection-simple.cs | Adds comprehensive tests for async method reflection behavior including dynamic invocation, interface mapping, and dynamic IL scenarios |
src/tests/async/Directory.Build.targets | Uncomments the DisableProjectBuild property to enable async test execution |
src/libraries/System.Private.CoreLib/src/Resources/Strings.resx | Adds error message for unsupported async infrastructure method invocation |
src/coreclr/vm/runtimehandles.cpp | Filters out async variant methods from RuntimeTypeHandle_GetMethodAt |
src/coreclr/vm/reflectioninvocation.cpp | Adds check to throw NotSupportedException when invoking async methods via reflection |
src/coreclr/inc/clrconfigvalues.h | Enables RuntimeAsync feature by default (changes default from 0 to 1) |
src/coreclr/System.Private.CoreLib/src/System/RuntimeType.CoreCLR.cs | Updates GetInterfaceMap to handle null method handles and resize arrays when async variants are filtered out |
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
Closes: #115099
Closes: #115101
This is a follow up that addresses a few concerns around reflection behavior with Async/Task-returning methods and adds tests.
The general theme for reflection is that async variant methods "do not exist". This is the least confusing approach, since these methods are not present in the IL. It also avoids issues with representation of the variants and their invokability.
There is one caveat around infrastructure helpers like
Await
/AwaitAwaiter
. These are visible in reflection, since they are present in the IL, but they are async methods.Ideally they should not be invokable form non-async methods and this change makes reflection invoke to throw for them.
NOTE: It is still possible to construct dynamic IL that calls the helpers from non-async caller. This is a fairly advanced scenario that is unlikely to happen by accident. It may be ok to leave this for v11.
In this change:
Query by name skips async variants, returns actual methods in IL. This was the case even before this change.
AsyncHelpers.Await
via reflection: possible.AsyncHelpers.Await
via MethodInfo Invoke: throwsThe message says: "Async infrastructure methods are not supported in reflection invocation."
Getting methods by a slot number is an internal API. There is observable impact on the
GetInterfaceMap
, which before this change could return duplicate mappings for Task-returning methods due to presence of other variants.MethodImpl.Async
- can await via Await pattern, can be called and can be awaited.MethodImpl
flags to these methods through current APIs.