Declaring a local function with a flexible type breaks TaskBuilder

Repo with reproducable example: https://github.com/dkcsiltberg/FSharpTaskBuilderExample

We tried going from TaskBuilder.fs to the native TaskBuilder, and ran into a problem where TaskBuilder would either not compile or behave strangely runtime. It did not happen with TaskBuilder.fs. We isolated the issue to declaring a local function that took a flexible type as an argument. Here is the code in the example repo that causes the issue:

task {
    let m1 f s = Seq.map f s // doing this is fine

    do! Async.Sleep 1
    do! System.Threading.Tasks.Task.Delay 1

    let m2 f (s: #seq<_>) = Seq.map f s // doing this is not fine

    try
        do! Async.Sleep 1 // this crashes
        printf "wow I made it\r\n"
    with _ ->
        printf "nope\r\n"

    do! System.Threading.Tasks.Task.Delay 1 // this just never resumes
    printf "wow I made it\r\n"

    return 1
}
|> fun f -> f.Wait()
System.Console.ReadLine () |> ignore

Repro steps

1. Declare a local function in a task computation expression
2. Do some sort of bind operation after that declaration
3. Try to run it

Expected behavior

Should compile and resume properly

Actual behavior

50% of the time it doesn’t even compile with the error FS0073 internal error: The local field ResumptionDynamicInfo was referenced but not declared

When it compiles, all the binds after the function misbehaves in different ways depending on what it is awaiting. Async.Sleep causes it to crash with a null reference exception, and Task.Delay causes it to wait forever and never resume.

Known workarounds

Declare the function outside the comp expr or use TaskBuilder.fs

Related information

• Operating system - Windows 11
• .NET Runtime kind (.NET Core, .NET Framework, Mono) - .NET Core 6.0
• Editing Tools (e.g. Visual Studio Version, Visual Studio) - VS 2022

[psfinaki]

Some more notes from the session with @dsyme:

1. Pipes are unrelated here
2. The state machine is not kicking in
3. This reproduces only with --optimize- option, for end-users it means Debug mode (in tests we --nooptimize should be specified explicitly)
4. When --optimize- is set state machine compilation does kick in

To be continued.

[psfinaki]

Alright so the minimal repro I have is the following:

task {
    let m f (s: #seq<_>) = Seq.map f s
    do! System.Threading.Tasks.Task.Delay 1
}
|> ignore

I mean this reproduces the issue of having different rebuild versus build results.