[RuntimeAsync] Remove no longer needed workarounds for Roslyn NYIs #120895
Conversation
VSadov
added
test-enhancement
VSadov
changed the title
|
Tagging subscribers to this area: @mangod9 |
|
/ba-g this is a test-only change in a disabled test area. (verified that it passes when enabled) |
There was a problem hiding this comment.
Pull Request Overview
This PR modernizes the async struct test by removing obsolete workarounds. The changes eliminate manual @this variable copies that were previously needed to work around C# compiler limitations in a prototype phase, simplifying the code to use this directly.
Key Changes
- Removed TODO comments and manual
@thisvariable workarounds from async methods - Direct usage of
thisin struct async methodsTest()andInstanceCall()
| AssertEqual(100, this.Value); | ||
| this.Value++; | ||
| await this.InstanceCall(); | ||
| AssertEqual(101, this.Value); | ||
|
|
||
| AssertEqual(100, @this.Value); | ||
| @this.Value++; | ||
| await @this.InstanceCall(); | ||
| AssertEqual(101, @this.Value); | ||
|
|
||
| await @this.TaskButNotAsync(); | ||
| AssertEqual(102, @this.Value); | ||
| await this.TaskButNotAsync(); | ||
| AssertEqual(102, this.Value); |
There was a problem hiding this comment.
The test expects this.Value to remain 101 after the async operation (line 53), but since structs are value types and this is passed by value to async methods, mutations in InstanceCall() won't affect the caller's copy. After removing the @this workaround, this test logic may be incorrect unless the C# compiler now generates code to properly handle struct mutation across await points with by-ref semantics.
2 participants
Async methods in structs can compile and work correctly now.
This is a test-only change that removes workarounds.