JIT: Disallow widening tailcalls in async functions #119145
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The JIT allows tailcalls that depend on widening happening in the callee: e.g. an int32 returning function can tailcall an int16 returning function because the managed ABI specifies that the callee will widen anyway. However, this is not legal for async methods. For async methods the int32 and int16 returning functions come with two different resumption stubs that are responsible for propagating the returned result into the next continuation in asynchronous cases. Allowing an int32 -> int16 tailcall means only a 16-bit value gets propagated into a caller that expects 32 bits to be written into its continuation. Fix dotnet#119060
Member
Author
|
PTAL @dotnet/jit-contrib |
Contributor
There was a problem hiding this comment.
Pull Request Overview
This PR fixes a JIT compilation issue where widening tailcalls were incorrectly allowed in async functions. The problem occurs when an async function returning a wider type (e.g., int32) attempts to tailcall an async function returning a narrower type (e.g., int16), which can corrupt the continuation mechanism in async execution.
Key changes:
- Modified JIT logic to disallow widening tailcalls specifically for async functions
- Added comprehensive test case demonstrating the problematic scenario
Reviewed Changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| src/coreclr/jit/importercalls.cpp | Added check to prevent widening tailcalls in async functions |
| src/tests/async/widening-tailcall/widening-tailcall.cs | Test case reproducing the async widening tailcall bug |
| src/tests/async/widening-tailcall/widening-tailcall.csproj | Project file for the new test |
Contributor
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
EgorBo
approved these changes
Aug 28, 2025
jakobbotsch
commented
Aug 28, 2025
Member
Author
|
/ba-g Deadlettered |
Member
Author
|
/backport to release/10.0 |
Contributor
|
Started backporting to release/10.0: https://github.com/dotnet/runtime/actions/runs/17299660780 |
4 tasks
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The JIT allows tailcalls that depend on widening happening in the callee: e.g. an int32 returning function can tailcall an int16 returning function because the managed ABI specifies that the callee will widen anyway.
However, this is not legal for async methods. For async methods the int32 and int16 returning functions come with two different resumption stubs that are responsible for propagating the returned result into the next continuation in asynchronous cases. Allowing an int32 -> int16 tailcall means only a 16-bit value gets propagated into a caller that expects 32 bits to be written into its continuation.
Fix #119060