Implement conditional, printing, and enabled/disabled breakpoints

[ydeltastar]

• Closes: Add conditional/printing breakpoints godot-proposals#909

Adds advanced breakpoints and related editor features to work with them.

Features

• Conditional breakpoints using Expression evaluation.
• Print breakpoints using string interpolation. Supports member and stack variables Node {name} : {event}.
• Can disable suspending execution. Useful for print-only breakpoints.
• Enable/disable or edit through the code editor or the breakpoint tree's context menu.
• Support for passing settings by command line. -b res://script.gd:55|print=Print:%20{event}

I didn't make relevant changes in this PR for the DAP support which is used by the godot-vscode-plugin but the groundwork is done should someone want to implement it.

[ckaiser]

Tested, works as expected.

The conditions are pretty powerful, I'm a fan. It does let you shoot yourself in the foot by calling functions with side effects, but I'm not opposed to that being a thing that's allowed.

One thing I could see being improved is the text for the "Print" placeholder, I had to resize the window to finish reading it and find out it's with {var_name}, it's a minor thing but the text could be condensed or the sizing adjusted.

Checking the validity of the expression within the dialog, if possible, would be great as well, so you can see if you've made a syntax error (I accidentally tried to use || instead of or for example).

Overall though this is great, very useful and I'd love to see it get merged. Did not look at the code or documentation, just functionality.

[ydeltastar]

I modified the print hint text.

Checking the validity of the expression within the dialog, if possible, would be great as well, so you can see if you've made a syntax error (I accidentally tried to use || instead of or for example).

|| is a valid operator in GDScript.
I added an expression parsing error label but note that it can only catch basic syntax errors.

[Calinou]

Tested locally, it works as expected.

The idea of having non-suspending breakpoints is a great one; finally I may no longer have to rely on print() statement debugging so much 🙂

Some feedback:

• Using an unknown variable name (e.g. counters >= 10 instead of counter >= 10 in the above example) will fail silently. This should probably print an error when the line is first reached (but without breaking).
• Using an unknown print name (e.g. Value of counter: {counters} instead of Value of counter: {counter}) won't replace the placeholder and no error is printed. I'd expect it to print an error (and leave the placeholder as-is).
• Prints could make use of print_line_rich() instead of print_line() so you can use BBCode formatting within them. Right now, BBCode is printed as-is ([color=red]{counter}[/color] won't show up in red).
• When a breakpoint has Suspend Execution disabled, it should have a different icon to distinguish it from breakpoints that don't suspend execution. This could be an outlined red circle, for instance. For conditional non-suspending breakpoints, the = sign could be present in red in the middle.
• Since we have some space, we could rename Suspend Execution to Suspend Execution if Condition is Met just to be clear.
• Changes are occasionally lost after I close and reopen the Edit Breakpoint dialog. It's inconsistent and I can't determine a pattern as to why it's occurring.
• The error message that occurs when you use an invalid expression (I used : for my testing) isn't very clear. While the editor does point back to the script line where it occurred, it doesn't tell you that it's coming from an invalid conditional breakpoint. Ideally, it should do that, but also print the expression that was attempted to be parsed. (Printing the expression could also be done at the Expression class level.)

(I accidentally tried to use || instead of or for example).

It's strange that this is invalid in Expression, considering it's valid in GDScript (even if the preferred syntax is or as per the style guide).