-
Notifications
You must be signed in to change notification settings - Fork 29k
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
Debugger: Exclude caller from breakpoint hit condition #127775
Comments
I like the overall push to make Conditional Breakpoints and Hit Count breakpoints easier to use, since currently they are a bit hidden and not so easy to use as you say. As for this particular action: we could only do it when the debug adapter supports the hitBreakpointIds since then we can correlate between a stopped event and a breakpoint. So in case the You idea to use conditions to control this would not easily work for every language, so I think we need something more general. @weinand for ideas |
I like this idea. This would probably only apply in the current session. Would there be UI to remove or clear skipped callers? That will increase the size of DAP surface area. |
Is the context menu contributable by extensions? If so, I think for now this can be entirely implemented in vscode-debug. If users like it, it can get a proper UI. |
Indeed, that should be possible given we have good enough context keys and data passed when the command is executed |
The feature request makes sense, but I don't think that the feature is related to (or needs to be based on) breakpoint conditions or hit counts. IMO the requested feature is orthogonal to breakpoint conditions or hit counts (and it would not make breakpoint conditions or hit counts more discoverable). Another similar mechanism which exists for JS/TS debugging is the "skipFiles" concept. Here a set of files can be specified in the launch config through glob patterns and if program execution stops in the specified files, the debug adapter automatically executes a But this mechanism is not a good fit for the requested feature: "skipFiles" is too coarse grained and and it does not cover the concept of a caller context ("skip this breakpoint if the code is called directly or indirectly from method 'foo'"). So we can either try to extend the existing mechanisms from above for this feature or we can introduce a new mechanism. Let's first try to to extend existing mechanisms:
Of course for both cases context menu actions ("Ignore breakpoint in the context of this caller") would be provided as "short cuts", so a user does not have to edit a condition or the launch configuration. Alternatively we could introduce a new mechanism either
BTW, I wonder whether (and how) feature request https://github.com/microsoft/vscode/issues/127886 is related... @hediet @roblourens @connor4312 what do you think about this assessment? |
I dearly miss this feature. But yeah, conceptually this is very similar.
I like this approach! But in general such language injections can cause problems.
I fear this could impact performance and debugging stability, especially when excluding hot paths. |
Yeah, may be. But I'm not aware of any runtime/debugger that would allow for a native implementation of the "exclude caller" feature. So the "exclude caller" condition will be executed either in the DA or in VS Code.
VS Code knows nothing about the syntax of breakpoint conditions. They are just passed as strings to the DA. The DA is free to represent them in whatever form it wants. |
I agree that this shouldn't be based on conditional breakpoints. There is precedence for having "magic" in expressions, such as using the Something I am unsure about is the longevity of this "Ignore Caller" action (and similarly the "Never Break Here" in microsoft/vscode-js-debug#1095). When I'm debugging a program, I'm examining a particular facet of the program, so while I may want to ignore a caller or file at one point this isn't necessarily something I was persisted or committed. I think instead they should be stored in memory or in workspace storage, and (thinking for the moment that this would be custom functionality in js-debug) I could register tree views which show skipped/ignored files and allow them to be mutated.
The presence of this feature alone would have a negligible impact on performance if unused--a couple extra |
Not happening this milestone, moving to October |
I think I want to do this, but next iteration is housekeeping. Bumping to Nov. |
In JavaScript debugging, there's a context menu action to exclude a specific calling location from breaking at the current paused location. The currently excluded callers are shown in a basic tree view, which allows going to and removing locations These are only persisted in memory right now, so reloading will clear any currently-excluded locations. |
Looks like this was implemented - can you please reference the commits for the feature/docs allowing other debuggers to add the same feature? |
This was implemented using existing VS Code extension points and APIs (the only tweak in core was to add additional context to actions on the call stack). E.g. actions were contributed to the context menu and view and then a tree view and TreeDataProvider was implemented in js-debug. |
Great feature! Hey, does this also work for exception breakpoints, e.g. never break on lines where the exception is expected, like when checking browser capabilities by seeing if a particular piece of code will throw, or React Suspense's use of exceptions to interrupt rendering? |
Yep, it works for every type of pause, including exception breakpoints. |
It is now about the 20th time that I wished I had this feature, so I'm finally filing this feature request.
I think the UX around breakpoint hit conditions can be improved.
Similar to log points I find breakpoint conditions not very accessible (but this might be a personal preference). Thus, I rarely use them even though they could solve some problems I encounter during debugging.
Maybe this is because I'm usually using the mouse when debugging and "programming" the right stop condition requires context switches. Or because they require too many clicks to be setup. Whenever I use breakpoint hit conditions, I feel slow.
This feature is about making breakpoint hit conditions a little bit more accessible.
The Feature
It would be really nice if I could simply exclude a caller from a breakpoint hit condition:
If a breakpoint is hit and the statement that the breakpoint is on is about to be executed, I want to be able to right-click on some stack frame and have an option "Don't trigger breakpoint in this context".
If I click on it, the breakpoint hit condition should be extended to return
false
when the selected stack frame is still on the stack.This way, this breakpoint would never be hit when called from
renderLine
(becauserenderLine
is spammy, which makes it difficult to debug the actually problematic context):Implementation Details
This requires a small UI part (an additional context menu entry) and a larger debug adapter part (figuring out how to formalute the exclusion as valid JS condition, probably involving
new Error().stack
).More Ideas
I think these contextual actions make hit conditions way easier to use.
Maybe something like this could also make sense for the watch view - "Restrict hit condition to
x === 1
" (orx !== 1
), ifx
currently is1
.The text was updated successfully, but these errors were encountered: