Inline conditional runtime-async callbacks in a separate lowering pass

[majocha]

Fixes #20577

When an InlineIfLambda function or delegate still contains an Await after inlining, it used to be expanded at every call, which repeated its setup code and split up the state it captures. Now its setup runs once, recording which branch was chosen and the values that branch uses. Each call runs an inlined copy of the chosen body. Everything stays in the enclosing runtime-async method, so AsyncLocal changes made by the callback remain visible to the caller.

• Callback inlining and body preparation run in a lowering pass after the first optimization loop and before LowerLocalMutables, so they see the final inlined shape. Each marker body is prepared once, after the callbacks are inlined. As a result, an Await that ends up inside a with handler is now rewritten; before, it was missed.
• Inside runtime-async expansions, the optimizer moves captures wrapping an InlineIfLambda lambda out of its binding, so the normal inliner handles callbacks that don't branch.
• Each call copies every branch body. When the copies would exceed 2000 expression nodes, the callback is left as a closure.
• Suspensions left in unmarked delegate methods, in a callback over the size limit, or in a callback that is returned from try/with or called from inside a closure are reported as FS3918.

Composes with #20655.

Checklist

• Test cases added
• Performance benchmarks added in case of performance changes
• Release notes entry updated

[github-actions]

✅ Release notes checked

---

✅ Found changes and release notes in following paths:

Change path	Release notes path	Description
`src/Compiler`	docs/release-notes/.FSharp.Compiler.Service/11.0.200.md

[github-actions]

🔍 Tooling Safety Check — Affects-Build-Infra, Affects-Compiler-Output
Affects-Build-Infra: Changes compiler build project structure.
Affects-Compiler-Output: Changes emitted IL metadata behavior.

Generated by PR Tooling Safety Check · gpt56 2.5M · ◷

[T-Gro]

🤖 🕵️ AI review — verify independently.

[T-Gro]

🤖 🕵️ Re-reviewed all recent changes as of 123ba9f; 1 finding

[T-Gro]

🤖🕵️ [P2] Outer count becomes count (shadowed) at the first printfn, before the inner declaration, with --debug:portable --optimize-.

open System.Threading.Tasks
open System.Runtime.CompilerServices
open Microsoft.FSharp.Core.CompilerServices

let inline invoke ([<InlineIfLambda>] callback: unit -> int) : Task<int> =
    StateMachineHelpers.__runtimeAsyncReturn (callback ())

let run flag (ready: Task<int>) =
    let mutable count = 99
    invoke (
        if flag then
            printfn "outer = %d" count
            let mutable count = 10
            fun () ->
                let value = AsyncHelpers.Await ready
                count <- count + value
                count
        else
            fun () -> 0)

[majocha]

The size and complexity of this is getting out of hand. I'm thinking about returning to the outlining concept, with saving and restoring execution context at suspend boundaries. Ideally the runtime should provide a public way to transparently await a thunk, which is what we need here.

[T-Gro]

Can we do outlining safely also w.r.t to order of effects and mutation of locals?
I wonder if this isnt changing one set of issues for another.

[majocha]

Can we do outlining safely also w.r.t to order of effects and mutation of locals? I wonder if this isnt changing one set of issues for another.

I guess this all should be covered, because we no longer inline. The main issue is ExecutionContext: we need to continue on the outlined child context. Capturing the final state inside the outlined function and restoring it on resume does it. This will not prevent side effects like AsyncLocal change notifications. This means the execution will still be subtly different for outlined vs inlined callbacks.

[majocha]

I'll make a separate branch with a prototype, retaining all the regression tests from here.

[majocha]

Including this PR, there is now a sizeable catalogue of custom optimizations used by the runtime-async feature:

Custom optimization	What it does	Implementation
Await-input local elimination	Folds a single-use binding directly into an await/suspension argument, including through intermediate calls, coercions and constructions. Only moves past safe expressions, preserving evaluation order.	Optimizer.fs:1894–1947, inlineAwaitInput / ImmediateRuntimeAwait
Callback-capture floating	Rewrites let callback = (let capture = expr in fun x -> ...) into let capture = expr in let callback = fun x -> .... Also handles delegates and leading sequential expressions. This exposes the callback to ordinary inlining without duplicating construction effects.	Optimizer.fs:2721–2754, FloatInlineIfLambdaCaptures; runtime-async-only invocation at line 3298
Returned-closure application fusion	Pushes applications through let, let rec, sequencing and branch-selected returned functions, then beta-reduces the exposed lambdas. This brings suspensions out of returned closures and into the enclosing runtime-async body. Branch distribution and curried reduction have effect-safety checks.	RuntimeAsyncAnalysis.fs:140–216, ReduceRuntimeAsyncReturnedClosureApplications
Single-use suspending delegate fusion	Eliminates a residual delegate construction plus Invoke, including supported wrapped or conditional constructions, by substituting the delegate body at its sole invocation. Construction must be safe to move.	LowerRuntimeAsync.fs:297–365, 410–419, tryPrepareDelegateInvocation / inlineDelegate
Branch-selected callback defunctionalization	Replaces a suspending [<InlineIfLambda>] function or delegate selected by a conditional/match with a branch tag and hoisted captures. Each invocation becomes branch dispatch with copied bodies, rather than closure invocation. Construction runs once; mutable captures retain shared storage. Total copied branch-body size is capped at 2,000 expression nodes across invocations.	LowerRuntimeAsync.fs:90–270, 421–465, tryDefunctionalizeCallback / mkCallbackDispatch

There is also runtime-async-specific reoptimization of debug pipe chains once synthetic pipe-input bindings are in scope (Optimizer.fs:4547–4553). That enables existing optimizations rather than introducing another independent rewrite.