JIT: Check for inline candidates in gtTreeContainsAsyncCall

[jakobbotsch]

Inline candidates can later be substituted for the original call. That call may contain async calls, in which case the same spilling behavior should kick in.

Fix #124496

[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 a JIT code generation bug where async calls within inline candidates were not properly detected, causing incorrect register/memory handling that led to null reference crashes in Native AOT scenarios with runtime async enabled.

Changes:

• Enhanced gtTreeContainsAsyncCall to recursively check inline candidates within GT_RET_EXPR nodes for async calls
• Updated lambda capture from [] to [=] to enable the recursive member function call

[jakobbotsch]

cc @dotnet/jit-contrib PTAL @EgorBo

[MichalStrehovsky]

Do we understand why only native AOT was hitting this? Is this not hittable with the VM-based runtime? (Asking because I see there's no targeted regression test)

[jakobbotsch]

Do we understand why only native AOT was hitting this? Is this not hittable with the VM-based runtime? (Asking because I see there's no targeted regression test)

I would expect regular coreclr to be able to hit this too, but we aren't building the libraries (like Microsoft.Extensions.Caching.Memory) with runtime async in the regular coreclr yet. Plus, we only very recently enabled the inline candidates that are required for this to reproduce in #124183 -- before that PR I wouldn't expect this to repro. Furthermore to hit this problem requires boxing the result of a late rejected async inline candidate which is probably a rare situation.

Asking because I see there's no targeted regression test

So far I haven't been adding regression tests for async specific issues that we are finding in our existing testing.

[jakobbotsch]

Although it seems like we would expect to hit the issue in #124527. There is probably some element of randomness in the test itself around where the actual suspensions happen (that would explain why it didn't reproduce consistently for us).

[MichalStrehovsky]

Although it seems like we would expect to hit the issue in #124527. There is probably some element of randomness in the test itself around where the actual suspensions happen (that would explain why it didn't reproduce consistently for us).

Yep, that's where I would expect to see this too and why I asked!

[jakobbotsch]

I took a closer look and:

• It does not fail on Windows because we are boxing a System.Guid return, and on Windows those are returned via return buffer, which causes the JIT to evaluate the return value into a separate local, avoiding a byref that is live across the suspension
• On Linux it does not fail on coreclr in [RuntimeAsync] Enable runtime async in Libraries partition #124527 because the test never tiers up the particular function. If I set DOTNET_TieredCompilation=0 explicit then the test does fail as expected.

[MichalStrehovsky]

I see, thank you for checking!

I assume we're going to get coverage for these (tiering disabled, etc.) with CoreCLR in our various outerloops once runtime async is enabled by default.

[jakobbotsch]

I see, thank you for checking!

I assume we're going to get coverage for these (tiering disabled, etc.) with CoreCLR in our various outerloops once runtime async is enabled by default.

Yes, I would expect so. If anything libraries-jitstress runs all the libraries tests in a number of different configurations, including with and without tiered compilation.