[RuntimeAsync] Fix Await pattern detection for ValueTask in ConfigureAwait cases.

[VSadov]

Fixes: #119617

Since ValueTask is a struct, we need to see through stloc; ldloca; sequence when matching ConfigureAwait call

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull Request Overview

This PR fixes await pattern detection for ValueTask in ConfigureAwait cases by recognizing the stloc; ldloca; instruction sequence that occurs when ConfigureAwait is called on ValueTask (a struct type). The fix enables proper optimization of ValueTask await patterns in runtime async methods.

Key Changes:

• Enhanced IL pattern matching to detect stloc; ldloca; sequences before ConfigureAwait calls
• Changed return type of impMatchTaskAwaitPattern from bool to pointer for better control flow
• Enabled runtime async tests by default

Reviewed Changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/coreclr/jit/importer.cpp	Added logic to detect and validate stloc/ldloca sequences in ValueTask ConfigureAwait patterns
src/coreclr/jit/compiler.h	Changed impMatchTaskAwaitPattern signature to return position pointer instead of bool
src/coreclr/inc/clrconfigvalues.h	Enabled RuntimeAsync feature by default (changed from 0 to 1)
src/tests/async/Directory.Build.targets	Removed property group that disabled async tests
src/tests/async/Directory.Build.props	Added SYSLIB5007 to NoWarn list
src/tests/async/struct/struct.cs	Added opt-out attributes for async methods in structs pending Roslyn support

[jakobbotsch]

LGTM except the nits about nullptr vs NULL

[hez2010]

Wondering whether such optimization can be done in VN as well instead of the importer only so that it can capture more patterns that are not awaiting the Task/ValueTask{.ConfigureAwait()} directly?
For example,

var t = FooAsync();
Bar();
await t.ConfigureAwait(false);

[jakobbotsch]

Wondering whether such optimization can be done in VN as well instead of the importer only so that it can capture more patterns that are not awaiting the Task/ValueTask{.ConfigureAwait()} directly? For example,

var t = FooAsync();
Bar();
await t.ConfigureAwait(false);

It would not help your case. There is no way to call the async version of FooAsync without waiting for its completion, which is not the semantics of this program that runs Bar after starting FooAsync.

We may still do an optimization like this in the future of we find that some cases we aren't getting (perhaps after inlining). But it is not so simple because currently finding the async variant of a method requires token information, and we do not keep token information around. We will either need to do that or only do the optimization for statically resolvable calls.

[VSadov]

GCC complained that CEE_STLOC and CEE_LDLOCA are out of range of the switch value (uint8_t). I think GCC is right about this. These are wide opcodes.