Runtime async via intrinsic by majocha · Pull Request #20235 · dotnet/fsharp

majocha · 2026-08-08T07:15:38Z

Yet another proof of concept (see also #19449)

The experiment here is to explore viability of working CE builders with just a minimal compiler support.

consider

__runtimeAsync: 't -> Task<'t>

intrinsic, which when used as a member or function body, promotes it to managed async.

We can have a fully inlining builder which wraps the code in it's Run method:

member inline _.Run([<InlineIfLambda>] code) = __runtimeAsync (code())

Because resumption is handled by the runtime, the builder is effectively just a sync builder with

member inline _.Bind(task, [<InlineIfLambda>] continuation) = AsyncHelpers.Await task |> continuation

There are more concerns than suspension / resumption that the runtime apparently does not handle and they would have to be covered either by the compiler or the builder implementations:

awaits in EH blocks (IAsyncDisposable) - this has a PoC in the tests here.
byref locals and execution context / sync context, see C# docs below.

runtime spec :
Runtime-async specification

interesting docs on C# implementation

github-actions · 2026-08-08T07:15:49Z

❗ Release notes required

You can open this PR in browser to add release notes: open in github.dev

✅ Found changes and release notes in following paths:

Change path Release notes path Description

`src/FSharp.Core` docs/release-notes/.FSharp.Core/11.0.100.md

`src/Compiler` docs/release-notes/.FSharp.Compiler.Service/11.0.100.md

`src/Compiler/Facilities/LanguageFeatures.fsi` docs/release-notes/.Language/preview.md

…c; add Language preview release notes The features dictionary lost ImplicitDIMCoverage, MethodOverloadsCache, ErrorOnMissingSignatureAttribute, DirectDelegateConstruction, AccessProtectedBaseFieldFromClosure and RecordSpreads entries, causing 54 CI test failures ('Unable to find feature' internal errors and preview features not enabled). Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

T-Gro · 2026-08-12T08:17:12Z

 Microsoft.FSharp.Core.CompilerServices.SetStateMachineMethodImpl`1[TData]: Void Invoke(Microsoft.FSharp.Core.CompilerServices.ResumableStateMachine`1[TData] ByRef, System.Runtime.CompilerServices.IAsyncStateMachine)
 Microsoft.FSharp.Core.CompilerServices.StateMachineHelpers: Boolean __useResumableCode[T]()
 Microsoft.FSharp.Core.CompilerServices.StateMachineHelpers: Microsoft.FSharp.Core.FSharpOption`1[System.Int32] __resumableEntry()
+Microsoft.FSharp.Core.CompilerServices.StateMachineHelpers: System.Threading.Tasks.Task`1[T] __runtimeAsync[T](T)


So this would be the only public addition and initial usage would come via library provided CE ?
(I agree its better to keep it out of dotnet/fsharp to iterate faster, and only move once stabilized 👍 )

Yes, I guess we cannot just replace current task builder implementation while the library is ns21. (not sure about it).

From agility perspective, I feel like its better to start with it outside of dotnet/fsharp.
Btw. this intrinsic might be a good candidate for - #20229 .

That eliminates a class of issues of people targeting it with an unsupported runtime.

With #20229 , the implementation of the library addition (now just the slim intrinsic) might also be doing calls to the BCL apis for AsyncHelpers (or better leave those to the CE implementation ?)

T-Gro · 2026-08-12T08:19:26Z

            "__stateMachine should always be guarded by __useResumableCode and only used in valid state machine implementations"

+    [<MethodImpl(MethodImplOptions.NoInlining)>]
+    let __runtimeAsync<'T> (value: 'T) : Task<'T> =


Why a fail and not a retype?

I also wonder about the "older compiler, newer Fsharp.Core" consequences here.

Retype as in different nominal type than actual resulting type? The idea here is to have it typecheck correctly with no extra compiler work. By the spec we need the resulting method to actually return 't, but have a Task<'t> nominal return type, so this covers it. During typecheck we got Task<'t> just from the signature here. Optimizer erases __runtimeAsync and we emit async method which returns 't just like the runtime expects.

As for FSharp.Core / compiler mismatch, this is, kind of like __stateMachine, an "expert" feature for authoring CE builders or low level runtime async methods. The fail with unsupported compiler is same behavior as __stateMachine.

Got it, this is just for the final return/Run.

Maybe the name could indicate it?
Like __return_from_runtimeAsync ?

Yes, that's the intent . more ideas: __asyncReturn, __runtimeAsyncReturn

T-Gro

🕵️🤖 A couple more notes without inline anchors:

Non-generic Task/ValueTask returns are silently unsupported — worth a diagnostic so it errors instead of miscompiling (docs L31).
ILVerify can't verify async-returning methods yet, so this codegen stays unverified in CI — known gap.

Backed by a small runtime-async edge-case suite (runtime behavior + emitted IL) driven through a test-only runtimeTask CE.

T-Gro · 2026-08-13T11:25:36Z

                .WithSynchronized(hasSynchronizedImplFlag)
-                .WithNoInlining(hasNoInliningFlag)
                .WithAggressiveInlining(hasAggressiveInliningImplFlag)
+                .WithAsync(isRuntimeAsync)


🕵️🤖 With the method marked async here, remember to also disallow .tail in the body — ilverify flags TailRetType on a tail-call after Await.

F# test

[<Fact>] let ``runtime async currently emits a forbidden tail prefix (C1)`` () = compileDirect "let f (g: int -> int) (x: int) : Task<int> = StateMachineHelpers.__runtimeAsync (AsyncHelpers.Await(Task.Delay(1)); g x)" |> verifyILContains [ "tail." ] // .tail is emitted today; ilverify -> TailRetType |> shouldSucceed

T-Gro · 2026-08-13T11:25:36Z

+
+* `tail.` and `localloc` are forbidden.
+* suspension cannot occur inside exception-handling regions. Awaiting in a
+  `try` body now works on the current runtime; awaiting inside a `finally`


🕵️🤖 await in finally/catch compiles with no diagnostic and fail-fasts at runtime (0xC0000409) — wants a real error eventually.

F# test

[<Theory>] [<InlineData("await-in-finally", "let f () : Task<int> = StateMachineHelpers.__runtimeAsync (try 1 finally AsyncHelpers.Await(Task.Delay(1)))")>] // runtime: fail-fast 0xC0000409 / SIGSEGV [<InlineData("await-in-catch", "let f () : Task<int> = StateMachineHelpers.__runtimeAsync (try failwith \"boom\" with _ -> AsyncHelpers.Await(Task.Delay(1)); 7)")>] // runtime: crash let ``contract-forbidden suspension pattern compiles with no diagnostic`` (_label: string) (body: string) = compileDirect body |> shouldSucceed // NO diagnostic today

T-Gro · 2026-08-13T11:25:36Z

+  `try`, then restores a pending exception. This makes `use` on an
+  `IAsyncDisposable` work under runtime async (`testUsingAsyncDisposableSync`
+  executes).
+* Byref, byref-like, and pinned locals cannot be preserved across suspension.


🕵️🤖 Same undiagnosed gap for ref-struct/byref across a suspension (→ IndexOutOfRange at runtime); C# gives CS4007/CS1988.

F# test

[<Theory>] [<InlineData("refstruct-across-suspension", "let f () : Task<int> = StateMachineHelpers.__runtimeAsync (let data = [| 10; 20; 30 |] in let span = ReadOnlySpan<int>(data) in AsyncHelpers.Await(Task.Delay(1)); span[0] + span[1] + span[2])")>] // runtime: IndexOutOfRange (C14) [<InlineData("byref-param-across-suspension", "let f (x: byref<int>) : Task<int> = StateMachineHelpers.__runtimeAsync (AsyncHelpers.Await(Task.Delay(1)); x)")>] // C# gives CS1988 let ``contract-forbidden suspension pattern compiles with no diagnostic`` (_label: string) (body: string) = compileDirect body |> shouldSucceed // NO diagnostic today

majocha · 2026-08-13T17:22:20Z

Another thing to think through is inlining. Currently there are no checks at all for use of suspending AsyncHelpers members outside of an async method. According to spec, this is illegal but the idea is that any AsyncHelpers.Await calls should be contained by or inlined into the resulting async method (see the sample runtimeTask builder in the tests here). It seems to get an efficient single method from a CE the builder needs to declare every method inline and make use of InlineIfLambda.

Currently it is up to the "expert" user to not misuse AsyncHelpers. Ideally the compiler should check for any such illegal calls only after inlining.

This is still a sketch, but it successfully compiles runtimeTask builder. The builder passes ported Tasks.fs tests, which is promising.

T-Gro · 2026-08-14T10:48:53Z

Ideally the compiler should check for any such illegal calls only after inlining.

We could have a notion of PostIlxGen checks.
Agree it must run after all optimizations.

T-Gro · 2026-08-18T11:25:13Z

🕵️🤖 Parked a runtime-async edge-case suite on T-Gro/fsharp:runtime-async-edge-tests (rebased on your current head — top two commits, test-only) if you want to pick it up: runtime behavior + full-body / sequence-point IL through a test-only runtimeTask CE, pinning the four still-undiagnosed gaps (.tail after Await, await in finally/catch, byref/ref-struct across a suspension, non-generic Task/ValueTask) as regression tests. No rush — waits on this landing and the __runtimeAsyncReturn naming settling.

Roslyn-async2-inspired edge cases for the runtime-async intrinsic, driven through the test-only runtimeTask CE (treated as a hypothetical library): * execution fixture (RuntimeAsync/RuntimeAsyncEdgeCases.fs): locals/loops across suspension, non-ref struct across suspension, ValueTask operand, exception propagation, IAsyncDisposable with genuinely-async DisposeAsync. * facts (RuntimeAsyncEdgeCaseTests.fs): Await overload selection per operand type, no compiler state machine (direct + CE), the C1 forbidden `tail.` prefix, and a parametrized set of currently-undiagnosed contract-forbidden patterns (await-in-finally/catch, ref-struct- and byref-across-suspension). Every asserted IL substring and runtime symptom was captured empirically on the pinned net11 preview; the forbidden patterns match docs/runtime-async.md. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 55dd72c8-46d3-4959-9677-c52d41779596

The sequence-points baseline (and ildasm) cannot render MethodImplOptions.Async (0x2000), so the lifted __runtimeAsync body shows up as a plain outer@<line> closure. Factor the metadata flag check into assertAsyncFlagOnLiftedClosureOnly and chain it onto the sequence-points fact so the exact program that emits the .bsl also proves the async marker lands only on the lifted closure, never on the user's outer/helper methods. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 55dd72c8-46d3-4959-9677-c52d41779596

majocha · 2026-08-20T07:43:30Z

Looks like the runtime feature is quickly evolving, see #19056 (comment)

runtime-async-tiering-and-tail-await-optimizations

The previous run was SIGKILL'd by the OOM-killer mid-suite (0 real test failures; 229 tests never ran). Empty commit to re-run the pipeline. Same exit-137 flake also hit unrelated PRs #20274 and #20235 at the same time. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

majocha · 2026-08-20T21:36:58Z

I wonder how to support the other allowed return types.

__runtimeAsyncReturn<'T>       : 'T -> Task<'T>
__runtimeAsyncReturnValueTask<'T> : 'T -> ValueTask<'T>
__runtimeAsyncReturnUnit       : unit -> Task
__runtimeAsyncReturnValueTaskUnit : unit -> ValueTask

and it quickly becomes a whole zoo. Do we need the non-generic versions at all? Only for potential C# interop, I guess. The upside is that the current type check is all we need to keep it correct, without any extra handling.

The other alternative it to have a unconstrained __runtimeAsyncReturn: 'T -> 'Carrier and do extra checks that the 'Carrier type is supported.

…sharp into runtime-async-intrinsic

majocha · 2026-08-21T07:04:29Z

🕵️🤖 Parked a runtime-async edge-case suite on T-Gro/fsharp:runtime-async-edge-tests (rebased on your current head — top two commits, test-only) if you want to pick it up: runtime behavior + full-body / sequence-point IL through a test-only runtimeTask CE, pinning the four still-undiagnosed gaps (.tail after Await, await in finally/catch, byref/ref-struct across a suspension, non-generic Task/ValueTask) as regression tests.

I pulled them in and adjusted to withFSharpCoreShippedNet.

majocha · 2026-08-21T07:40:43Z

VerifySurfaceAreaFSharpCore still runs against ns21 baseline, I think.

majocha · 2026-08-21T08:01:51Z

Ideally the compiler should check for any such illegal calls only after inlining.

We could have a notion of PostIlxGen checks. Agree it must run after all optimizations.

The downside is the errors surface only during build, not in the IDE, just like with resumable state machines.

majocha · 2026-08-21T09:57:21Z

Regarding suspension in exception handling blocks, it's not hard to do a rewrite during optimization, just like C# compiler does.
If we are to detect and error on suspensions in EH, we might as well just rewrite.

majocha added 5 commits August 8, 2026 08:34

docs

15fff46

feature

0cc2108

tests

719d00f

surface area

f9bb483

rns

dfe4109

github-project-automation Bot added this to F# Compiler and Tooling Aug 8, 2026

github-project-automation Bot moved this to New in F# Compiler and Tooling Aug 8, 2026

majocha and others added 5 commits August 8, 2026 09:20

merge main

b06dd3d

translations

e4eb267

add pr numbers

38578d4

surface area

48d1691

T-Gro reviewed Aug 12, 2026

View reviewed changes

T-Gro reviewed Aug 13, 2026

View reviewed changes

Merge branch 'main' into runtime-async-intrinsic

eb32d05

T-Gro and others added 2 commits August 18, 2026 14:59

Merge branch 'main' into runtime-async-intrinsic

d29dc42

Merge branch 'main' into runtime-async-intrinsic

ca0ca40

majocha added 3 commits August 21, 2026 00:24

restrict to net10, rename to __runtimeAsyncReturn

6f8cadc

ns surfacearea

d5bd674

Merge branch 'runtime-async-edge-tests' of https://github.com/T-Gro/f…

19117fe

…sharp into runtime-async-intrinsic

adjust edge case tests to name change and net10 FSharp.Core

5154fa9

majocha added 4 commits August 21, 2026 13:14

rewrite runtime async exception handling blocks during optimization

b645d98

fix surface area

d50c33c

Merge branch 'main' into runtime-async-intrinsic

b9f9ef9

surf

27944e7

majocha force-pushed the runtime-async-intrinsic branch from 04e7fb3 to 27944e7 Compare August 22, 2026 08:26

Uh oh!

Conversation

majocha commented Aug 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented Aug 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

❗ Release notes required

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

T-Gro left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

majocha commented Aug 13, 2026

Uh oh!

T-Gro commented Aug 14, 2026

Uh oh!

T-Gro commented Aug 18, 2026

Uh oh!

majocha commented Aug 20, 2026

Uh oh!

majocha commented Aug 20, 2026

Uh oh!

majocha commented Aug 21, 2026

Uh oh!

majocha commented Aug 21, 2026

Uh oh!

majocha commented Aug 21, 2026

Uh oh!

majocha commented Aug 21, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

majocha commented Aug 8, 2026 •

edited

Loading

github-actions Bot commented Aug 8, 2026 •

edited

Loading