Stepping in computation expressions steps out on let!/do!

[cmeeren]

When stepping through computation expressions, the debugger seems to step out on let!/do! expressions. This is easily reproduced with async expressions, but I have also observed it for custom CEs. Setting breakpoints or using Run To Line works correctly, but Step Over or Step Into seems to break out on let!/do!.

Step Over:

Step Into (note also that it doesn't break out to main like Step Over does above - is this another bug?):

Run To Line:

Breakpoints:

Repro steps

ReproSolution.zip

Expected behavior

Step Over and Step Into should not step out of the expression after breaking on a let! or do!.

Actual behavior

Step Over and Step Into steps out of the expression after breaking on a let! or do!.

Furthermore, note in the Breakpoints example above that it breaks twice on the let! and do! lines. Is this another bug?

Known workarounds

None that I know of.

Related information

It's been like this for a long time, but this report was made using VS 15.6.4 and Visual F# nightly 15.6.20180504.1.

[abelbraaksma]

I'm not sure, but isn't this related to the asynchronous nature of, well, async? Does it exhibit the same behavior if you use, say, seq, query or a result builder?

[cmeeren]

Hmm, there certainly are some differences.

In this seq expression it doesn't break at all, even if I set breakpoints on every line in the expression: Edit: I forgot to evaluate the sequence, see two comments down.

let foo () =
  seq {
    let x = 2
    yield x
    let y = 3
    yield! [x; y]
    yield! seq { yield 4 }
  }

[<EntryPoint>]
let main argv =
  foo () |> ignore
  0

Using my ResultBuilder from cmeeren/Cvdm.ErrorHandling and the code below, breakpoints and Run To Line works correctly (same as for async), Step Into works correctly (though it breaks twice in a row on every do! line just like breakpoints does, and it also stops in main which is different from with async), but Step Over breaks out at the first do!.

let foo () =
  result {
    let x = 2
    do! Ok ()
    let! y = Ok 3
    return x + y
  }

[<EntryPoint>]
let main argv =
  foo () |> ignore
  0

When using AsyncResultBuilder from the same package and the code below, things work kinda the same, except that Step Into now jumps out after do! Async.Sleep.

let foo () =
  asyncResult {
    let x = 2
    do! Ok ()
    do! Async.Sleep 100
    let! y = asyncResult { return 3 }
    return x + y
  }

[<EntryPoint>]
let main argv =
  foo () |> Async.RunSynchronously |> ignore
  0

In any case, I'd say the expected behavior is for Step Over and Step Into to work as in C# async methods. The current behavior contributes to making debugging in F# more painful than it needs to be (AFAIK).

[abelbraaksma]

In this seq expression it doesn't break at all, even if I set breakpoints on every line in the expression:

That's correct, because you don't evaluate the seq expression, you only instantiate the builder, so it indeed never hits inside the builder. Try it with Seq.toList or Seq.toArray or Seq.iter to force evaluation.

though it breaks twice in a row on every do! line

I suspect that's because there's two function calls, one for Ok() and one for evaluating do! (which calls Zero iirc).

You may see different lines hit when you run it in Release mode, as some lines will be optimized away.

except that Step Into now jumps out after do! Async.Sleep.

My guess is here that during the sleep, the other methods have already been evaluated. But I agree, when you break, you should have 'break on all threads", which should block further processing. But since this is async, when the processor hits the break on your sleep-line, the other statements may have already been processed and only that line is still waiting completion. I'd assume that a similar thing can happen in C#, but the unwrapping of the code is quite different there so it may be hard to compare.

To fix that, you can place a breakpoint inside the builder itself, upon creation. I sometimes simply create a second builder-creation (let's say asyncResult2) for this purpose. Or place a breakpoint on the exact lines you want to step through (but you figured that out already in the OP).

Sometimes I can't place a breakpoint on any line I want (this happens, for instance, in blocks of a |> b |> c, where you cannot set a breakpoint on an individual a or b, but only on the whole block), in which case you can add a little debug-helper which calls Debugger.Break().

With that in mind I decided to see if that could work. Consider the following code, it is not possible to break on an individual line:

Suppose I want to break on string, I simply cannot do it. And the debugger won't let me step-through either (I have Just My Code on, but still, I would expect it to step through each |>). So I experimented a bit and that worked out better than I expected. Consider this:

module TestBreak =
    let inline (>?>>) fn condition =
        #if DEBUG
        if condition then
            fun currentArgument ->
                let res = fn currentArgument
                Debugger.Break()
                res
        else
            fn
        #else
            fn
        #endif

    let testBreak() =
        let v = 42

        [1;2;3]
        |> List.append [3;4;5]
        |> List.map ((+) v)
        |> List.map (string >?>> true)
        |> List.fold ((+) >?>> true) ""

In the above code you still cannot set a breakpoint, but the manual breakpoint will be hit regardless.

I now have information on the currentArgument, and the inlining gives me quite a good debugging experience. I haven't used this before, but this may help in the general case (debugging function items is a pain, you need to wrap them in a fun x -> yourFunction x, which is annoying) . And perhaps an improvement can be made to F# itself to do something like this automatically on hitting F9 on a function item.

Of course, this is not a solution to your question/bug, but perhaps it can be useful ;).

All that doesn't mean it cannot be improved. I'm just trying to figure out what causes this behavior, and to me, while a frustrating debugging experience, it isn't completely unexpected.

[cmeeren]

That's correct, because you don't evaluate the seq expression, you only instantiate the builder, so it indeed never hits inside the builder. Try it with Seq.toList or Seq.toArray or Seq.iter to force evaluation.

Ah, sorry for the brain fart. Using Seq.toList, Step Over and Step Into seem to work correctly (and identically) for the code I posted.

[abelbraaksma]

@cmeeren, happens to me all the time ;). I've updated my post while you were typing, maybe the code sample is useful :).

[cmeeren]

Thanks for the note. I see the benefit of your code and will keep it in mind. :) Though of course I don't like the fact that it's necessary.

A simpler alternative if one just wants the value at some point in a pipe chain (or something to mouse over at design time to see the type at that point), |> fun x -> x works well.

[abelbraaksma]

|> fun x -> x works well.

Yes, I've used that often, but with composition that can quickly get messy with added parens and everything. Here I wanted to break inside the list items, not the whole list.

But it would be so much nicer if this wasn't a (necessary) workaround for improving the debugging experience.

[dsyme]

I don't think this is a bug in the core F# implementation, since we don't specify the debugging behaviour of arbitrary CEs.

Related in #4867. As I outline there, getting good debugging even for the synchronous parts of delayed computations is hard, though progress has been made. And that only deals with stack traces, and not stepping.

What's I think is really needed is a comprehensive guide to writing CEs that have good debugging experiences (stack, stepping, exception stacks, breakpoints). The notes in #4867 are a good starting point for stacks.

I will close this as it's not specifically an actionable bug in the compiler.