Advance Debugging

[akosyakov]

What it does

• watch expression support #5769 - watch expressions
  • a CQ for add icon: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=20445 (resolved)
• exception breakpoints support #5768 - exception breakpoints
• function breakpoints support #5767 - function breakpoints
  • a CQ for function breakpoint icon: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=20470
• [debug] inline breakpoints support #3807 - inlined breakpoints
• identity of breakpoints are not preserved by plugins #5788 - fix identify of breakpoints in the plugin process
• add copyrights to all copied icons

Pause on an exception with watch expressions:

How to test

• watch expressions: add watch expressions and start debugging, they should be updated as you go

• exception breakpoints:

  • they are provided by a debug adapter on the first run, so start debugging something
  • after that you can enable them
  • after the debug session is finished, such breakpoints should be preserved anyway and reevaluated on next run
  • when exception breakpoint hits you should be able to see the reason in an editor

• function breakpoints:

  • install nodejs vscode extensions, https://marketplace.visualstudio.com/items?itemName=ms-vscode.node-debug2 and https://marketplace.visualstudio.com/items?itemName=ms-vscode.node-debug
  • uninstall native Theia nodejs extension from example app and rebuild it
  • follow https://code.visualstudio.com/docs/nodejs/nodejs-debugging#_function-breakpoints
    • it works only with legacy protocol for Node.js < 8 and only for global functions which were already defined at runtime
      

• inlined breakpoints

  • look out for regressions with usual breakpoints, one should be able to mix them, disable, enable, edit on the same line via the context menu in the ruler and the breakpoints debug view

• breakpoints identity issues in the plugin host process: TBD

[tolusha]

@akosyakov Is it ready for review?

[akosyakov]

@tolusha I did not have time to add test sample VS Code extension to test identity of breakpoints in the plugin host process, but the rest should be good.

[tolusha]

@akosyakov
I probably won't be able handle this PR starting next week

[akosyakov]

@tolusha the problem is that we are going to prohibit to hard code colors in css, only css color variables can be used which are first registered via ColorContribution, i.e. all colors should be themable. This PR introduces such hardcoding.

You can change base of this PR to branch of #6722, introduce new colors and update css to use them. So this PR will be prepared for testing after theming PR is merged. Colors should be registered with ids as in VS Code, i.e. with debugExceptionWidget.background and debugExceptionWidget.border. For default values and descriptions please look up VS Code code base. After registration colors can be referenced in css with var(--theia-debugExceptionWidget-background) and var(--theia-debugExceptionWidget-border).

[akosyakov]

I'm going to reset base branch for it as #6722 and add missing colors.

[akosyakov]

I've fixed theming, so it should be fine to merge after the theming PR is in.

@thegecko I think all comments except using the context menu to add inline breakpoints were fixed. Would it be alright to tackle management of inline breakopints via the context menu separately? Right now one can add it by putting a cursor at some position and using the command palette, the debug top-level menu or the short-cut shift + f9.

@tolusha If you are fine with changes please don't forget to give an approve.

[thegecko]

@akosyakov, perhaps open an issue to add the context menu item? Happy to merge as is.

[akosyakov]

@thegecko I've filed an issue for inline breakpoints management with the context menu: #6795 I'm going to rebase the PR and if the build is green then merge it.

changes were addressed: #5774 (comment)