-
Notifications
You must be signed in to change notification settings - Fork 43
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
Add support for function breakpoints #136
Add support for function breakpoints #136
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This kind of change needs some kind of basic test please.
Tests would be a lot easier to write if they worked on MacOS or ran on PRs (with the output shown) |
Please add details on Issue #12 - or raise a new issue if needed. |
7c9230e
to
e46403b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In addition to the missing tests, this doesn't quite work. See spec:
↩️ SetFunctionBreakpoints Request
Replaces all existing function breakpoints with new function breakpoints.
The current implementation in this commit just keeps adding to the installed breakpoints. This probably wants to be merged with setBreakPointsRequest as that (sort of) handles the case.
As for a minimal test, something like this would be a start.
it('hits a function breakpoint', async () => {
await dc.setFunctionBreakpointsRequest({
breakpoints: [
{
name: 'main',
},
],
});
await dc.configurationDoneRequest();
const scope = await getScopes(dc);
const vr = scope.scopes.body.scopes[0].variablesReference;
const vars = await dc.variablesRequest({ variablesReference: vr });
verifyVariable(vars.body.variables[0], 'count', 'int', '0');
});
Although it would probably be better to add to count.c to add an additional function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the test. I think this still doesn't meet the DAP spec: #136 (review)
Still WiP |
94beca4
to
5da76e8
Compare
Rebased and added tests, still need to resolve the issue with not removing them... |
88fcd1f
to
8913455
Compare
@jonahgraham This should be good to go. I've got a change which de-duplicates the breakpoint resolving in |
Lets avoid the duplication in the first place - if you are ready to add it now, please do that. It will save me having to compare the setBreakpoints and setFunctionBreakpoints versions. |
Signed-off-by: Rob Moran <[email protected]>
8913455
to
a479033
Compare
@jonahgraham, I've introduced a common I've introduced a few more tests to exercise this new common function and I've tested it all locally. It's probably worth focussing your checks on the breakpoint handling overall as there is some churn in that area. I've also added a few minor bug-fixes and comments. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. I am going to do a touch of code cleanup as commented below and push it.
@@ -30,7 +30,7 @@ export interface MIBreakpointInfo { | |||
line?: string; | |||
threadGroups: string[]; | |||
times: string; | |||
originalLocation?: string; | |||
'original-location'?: string; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool, I didn't know you could do this. I am fixing up some other code because of this - PR coming soon.
(vsbp, gdbbp) => { | ||
|
||
// Always invalidate hit conditions as they have a one-way mapping to gdb ignore and temporary | ||
if (vsbp.hitCondition) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hitCondition
and condition
- VSCode does not yet have UI for this so it seems acceptable to not implement support for now, but we are at some point going to need our own fork of the debug protocol spec to document our differences and extensions and this is one of them.
const event = await dc.waitForEvent('stopped') as StoppedEvent; | ||
expect(event.body.reason).to.eq('function breakpoint'); | ||
const scope = await getScopes(dc); | ||
expect(scope.frame.line).to.eq(2); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is already a helper that does this:
dc.assertStoppedLocation('function breakpoint', {line: 2});
Signed-off-by: Rob Moran [email protected]
Introduced support for adding function breakpoints, see:
https://code.visualstudio.com/docs/nodejs/nodejs-debugging#_function-breakpoints