Runtime async via intrinsic

[majocha]

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

__runtimeAsyncReturn: '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. Wrapping the code in its Run method in __runtimeAsyncReturn will compile the whole CE into a single runtime async method:

member inline _.Run([<InlineIfLambda>] code) = __runtimeAsyncReturn(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

runtime spec :
Runtime-async specification

interesting docs on C# implementation

• Runtime-async code-generation contract
• Roslyn runtime async design
• 11 preview 7 changes

To do:

• decide on naming
• design and implement other allowed return types (ValueTask<_> and unit versions)
• awaits in EH blocks (IAsyncDisposable) - handled by rewriting the block to take suspensions outside
• byref locals not preserved across suspension - added diagnostic
• use of AsyncHelpers suspending methods outside of runtime async - added diagnostic
• handle --optimize- (debug configuration)
• fixed (pinned) locals not preserved across suspension - needs separate codepath
• implement IAsyncEnumerable, low level production and consumption
• test debug stepping / stack traces - tested manually, they are not great
• test AsyncLocals propagation
• add sample low level implementation of IAsyncEnumerable
• implement sample asyncSeq builder, test YieldFromFInal behavior
• update ildasm - separate PR, because of bulk baseline changes

[github-actions]

❗ 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

[majocha]

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]

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.

[majocha]

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

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

[majocha]

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.

[majocha]

Surprisingly, debug stepping across AsyncHelpers.Await more or less works out of the box:


at least with net11.0

However, it works like this only in simplest scenarios. Add some task CE in the mix and the call stack becomes mostly empty.

Stepping through runtimeTask CEs is possible, but misbehaves a lot, call stacks are non-existent, too.