Skip to content
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

Implementation of inline breakpoint #316

Open
zero-plusplus opened this issue Jan 18, 2024 · 0 comments
Open

Implementation of inline breakpoint #316

zero-plusplus opened this issue Jan 18, 2024 · 0 comments
Labels
draft Draft of new features enhancement New feature or request

Comments

@zero-plusplus
Copy link
Owner

zero-plusplus commented Jan 18, 2024

RELATED: #265, #315, #319

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.

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| return

If 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 here

The 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.

  1. customised step execution to the end of the method
  2. step over. In other words, move to the next method

The above steps can be used to break at a pseudo-target method.

@zero-plusplus zero-plusplus added enhancement New feature or request draft Draft of new features labels Jan 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
draft Draft of new features enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant