-
Notifications
You must be signed in to change notification settings - Fork 6
Description
I don't know if v2.0.0 will solve this issue, but it is an issue I would like to finally solve.
Why implement?
Inline breakpoints primarily solve the following problems.
- Behaviour of the breakpoint in Fat Arrow Function #315
- Improve debugging experience for method chains.For example, For example, only method d breaks in a method chain like
a.b().c().d()
Inline breakpoint is a feature that is not available in the AutoHotkey debugger. Therefore, they need to be controlled by debug adapter to behave like inline breakpoint.
Although not directly related to inline breakpoint, method chains containing line breaks such as the following must also be targeted.
1| a
2| .b()
3| .c()
4| .d()
5| returnIf you set a breakpoint on line c() in the example above, the debugger will re-set the breakpoint on line 5.
Also, the AutoHotkey debugger executes the c method immediately after the b method is executed.
In contrast, the node debugger returns to the first line of the caller after b() is executed. Then c() is executed and it returns to line 1 in the same way.
These differences can be seen when you do a step-out execution: in AutoHotkey, if you step out in the b method, it ignores the subsequent method chain and moves the cursor to line 5, which is the next statement.
In node debugger, step-out in the b method returns to the caller, so step-in execution can debug the c method.
This issue also deals with these.
Solution
Inline breakpoint in this situation behave like conditional breakpoint.
This breakpoint must be verified and its position corrected on behalf of the debugger.
This verification uses AELL (AutoHotkey Expression Like Language), which is enabled in v2.0.0.
As AELL supports AutoHotkey expressions, the following code can be analysed.
1| global Add := (a, b) => a + b
2| ; ^ Correct breakpoint position hereThe kind of expression must be determined by verification, and the correction one or behaviour must be changed depending on the kind of expression.
For example, if it is a Fat Arrow Function as shown above, the breakpoint is corrected to the position in the comment and the condition A_FuncName == "()" is set to the target breakpoint. Conversely, if the target breakpoint is not an inline breakpoint, the condition A_FuncName ! = "()". This condition controls whether the break occurs at the time of assignment or at the time of call.
Next, consider the following method chain.
a.b().c().d()For this problem, considering the behaviour of the AutoHotkey debugger as explained above, consider the following.
Verify the calling expression near the position to the inline breakpoint. Also, count the number of times the call expression is up to that position. After the step-in is executed, repeat the following steps for the number of call counts.
- customised step execution to the end of the method
- step over. In other words, move to the next method
The above steps can be used to break at a pseudo-target method.