Enabling debug breaks on |> operators
See original GitHub issueOpened by antofik at codeplex
Currently, I rarely use the |> operator because of their opaqueness in the debugger, and instead have to resort to series of var names that end with more and more prime symbols. The latter is error-prone, and I’d like to be able to use |>s more confidently in my code.
This issue suggests that |> be made to generate a sequence point, at least in debug builds, so that break points can be placed on them. Additionally, the intermediate results of |> chains would have to be represented as a specially-named variable in VS’s Locals variable viewer window.
Here’s the CC’d conversation as Don and I discussed it on Twitter - https://twitter.com/bryanedds/status/460140352213504000
comments KevinRansom wrote Apr 28, 2014 at 11:13 AM [x] This is a great suggestion, we would certainly be interested in seeing PRs to address this.
antofik wrote Nov 24, 2014 at 12:29 AM [x] Changing match case for SynExpr.Iden in UntypedParseInfo.ValidateBreakpointLocationImpl(range), ServiceUntypedParse.fs:124 enables us to set breakpoint on |> while in “Edit” mode. But while you are in “Debug” mode, breakpoint continues to slide to the whole line. It looks as if breakpoint changes location while changing state from Pending to Bind. And I cannot find in code nor implementation of IVsDebugger, nor implementation of IDebugPendingBreakpoint2. Am I correct assuming that F# uses some default debug engine?
brodyberg wrote Nov 24, 2014 at 7:43 AM [x] That’s interesting, I’ll see if I can repro that and look for the other interfaces you mention.
brodyberg wrote Nov 24, 2014 at 7:59 AM [x] Oh, one thing I gathered from speaking with Don Syme is that information is being lost at optimization time - for this reason I have been investigating this from the point of view of opt.fs, with a view toward identifying the information the structure has before and after optimization such that we can preserve information so the breakpoint remains after being optimized away.
antofik wrote Nov 25, 2014 at 12:35 PM [x] brodyberg, it’s quite easy to reproduce. Replace SyncExpr.Ident with following snippet (ServiceUntypedParse.fs163, walkExpr function:
| SynExpr.Ident op -> if rangeContainsPos op.idRange pos then match op.idText with | "op_PipeRight" -> yield! checkRange op.idRange | _ -> () else ()
Optimization - that’s quite understandable, though several questions arise. First, who is revalidating breakpoint after LanguageService has validated them? Second, we certainly would like to see intermediate results when stopped on |> instruction, so we need to add some autos (like $exception). But I cannot see how it can be done without direct access to the debug engine. Any ideas?
antofik wrote Nov 26, 2014 at 5:43 AM [x] Or, while in DEBUG mode, we can substitute |> definition with something like
let (|>) x f = let intermediate_result = f x ignore() // here we will place breakpoint intermediate_result
Issue Analytics
- State:
- Created 9 years ago
- Reactions:2
- Comments:8 (5 by maintainers)
Top GitHub Comments
Was this forgotten? Dropped? It would be great to see this implemented!
@KevinRansom ?