Skip to content

Unable to set a breakpoint in a back-piped function #11668

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
jbeeko opened this issue Jun 10, 2021 · 5 comments
Closed

Unable to set a breakpoint in a back-piped function #11668

jbeeko opened this issue Jun 10, 2021 · 5 comments
Labels
Area-Debug stepping, debug points, stacks and more Area-LangService-API Impact-Medium (Internal MS Team use only) Describes an issue with moderate impact on existing code. Regression
Milestone

Comments

@jbeeko
Copy link
Contributor

jbeeko commented Jun 10, 2021

In version 16.9.x it was possible to set a breakpoint on the lines of an anonymous function passed to a back pipe. In version 16.10.x this is no longer possible. The breakpoint is always set at the function level.

v16.10.0
image

v16.9.1
image

Repro steps
Start VisualSudio v16.10.x past the code into a .fs file and attempt to set a break point on the line printfn "line1".

let bodyRunner  body =
    printfn "running"
    body ()

let bodyWrapper =
    bodyRunner <| fun _ ->
        printfn "line1"
        printfn "line2"

Expected behavior
Be able to set a break point on the line

Actual behavior
Breakpoint set at function level.

Known workarounds
None

Environment

  • Windows 10 Pro 20H2
  • .NET Runtime .NET 5.0
  • Fails on v16.10.0 & v16.10.1.
@cartermp cartermp added Area-Debug stepping, debug points, stacks and more Area-LangService-API Regression Impact-Medium (Internal MS Team use only) Describes an issue with moderate impact on existing code. labels Jun 10, 2021
@cartermp cartermp added this to the 17.0 milestone Jun 10, 2021
@cartermp
Copy link
Contributor

I debugged this and confirmed there's a regression in the compiler here. One of the several PRs we took regressed on range generation for lambda expressions. The range of the body for the lambda only includes the argument(s); it doesn't have the body of the lambda anymore. Since that range is missing, the breakpoint resolution service ends up missing where you clicked and falls back to an outer scope.

@cartermp
Copy link
Contributor

Haven't dived into the history much myself, but @dsyme @auduchinok and @nojaf were the last folks who changed the parser between 16.9 and 16.10. Maybe this rings a bell?

See here: https://fsprojects.github.io/fantomas-tools/#/ast?data=N4KABGBEAmCmBmBLAdrAzpAXFSAacUiaAYmolmPAIYA2as%2BEkAxgPZwWQ2wAuYarALa8AFigDmYAPoAPMAF4wACgCUAHQBOa5Ju0DhPMckkAeAD6UArsmlgAtAD5dNiGAAOGlD3g21kAJ6wvH6QIAC%2BQA

The range for the lambda is correct in the fantomas web UI, but the range is incorrect when debugging the expression. So I suspect this is also an issue in Rider, VSCode, and anything else that would rely on the range.

@nojaf
Copy link
Contributor

nojaf commented Jun 11, 2021

Nothing comes to find for me. What timeframe are we looking at here?

@jbeeko
Copy link
Contributor Author

jbeeko commented Jun 11, 2021

I'll note that this prevents breakpoints in any of the "non-builder" style expecto tests. So it has a significant impact on those with a library of such tests.

@dsyme
Copy link
Contributor

dsyme commented Aug 20, 2021

Fixed in #11981

@dsyme dsyme closed this as completed Aug 20, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Debug stepping, debug points, stacks and more Area-LangService-API Impact-Medium (Internal MS Team use only) Describes an issue with moderate impact on existing code. Regression
Projects
None yet
Development

No branches or pull requests

4 participants