search

scalameta / metals-vscode

Visual Studio Code extension for Metals
https://marketplace.visualstudio.com/items?itemName=scalameta.metals#overview
Apache License 2.0
299 stars 75 forks source link

VS Code java debugger options such as "java.debug.settings.stepping.*" and "java.debug.settings.exceptionBreakpoint.*" are not supported. #1536

Open seantrow opened 1 week ago

seantrow commented 1 week ago

Describe the bug

When debugging scala programs through various means, the java.debug.settings.* settings are ignored by the java debug engine that metals uses.

To Reproduce Steps to reproduce the behavior:

  1. Open Settings UI
  2. Filter based on "debugger"
  3. Scroll down to "Show To String" (this is an easy one to check) - uncheck
  4. Run the debugger, still shows "toString" values (which is the default setting.)

Expected behavior

For the example above, the "toString" value should not be shown.
In general for debug settings, they should have the documented effect.

Screenshots

none

Installation:

Additional context

Per @tgodzik, these settings are known to be not implemented.

Search terms

java.debug.settings stepping skipClasses skipSynthetics skipStaticInitializers skipConstructors exceptionBreakpoint exceptionTypes showQualifiedNames showStaticVariables

seantrow commented 1 week ago

Just sniffing around to understand what is needed here - this is where the configuration should get read by the java debugger. https://github.com/microsoft/vscode-java-debug/blob/e4d2bf03877afe66d595ad489f2c634f2b474fb6/src/configurationProvider.ts#L792

seantrow commented 1 week ago

This is maybe more complicated than I imagined. It looks like the java debugger extension explicitly reads the settings from user config and marshals/sends them to the "redhat.java" extension with the "vscode.java.updateDebugSettings" command. There is enough other weird code around this path (e.g. handling dynamic updates of the settings and mixing other settings like javaHome) that it is sort of confusing what the details are.

seantrow commented 1 week ago

I added some code to mock what the vscode.java.debug is doing and send the message from ScalaMainConfigProvider.resolveDebugConfiguration. However I just get a "Type Error" when sending the config message. I don't have enough of an understanding of the big picture here to figure out the next step. (Happy to share the code if you like.)

tgodzik commented 6 days ago

@adpi2 would it make sense to somehow allow additional settings to be added to DAP? Are these part of the java debug server that we could reuse? I don't see anything related to this in base dap though.

adpi2 commented 4 days ago

@seantrow Thank you for looking into this. I have been thinking about it for a long time but never took the time to do it.

@tgodzik Yes the java-debug has some custom settings in its DAP requests. See for instance the Launch request, and the RefreshVariable request

We also have some custom settings in our Launch request.

So I think the goal is to get those settings from VSCode, and then to mix them in the DAP requests. I am not sure if the VSCode extension can do it directly. But maybe it can send those settings to Metals, and then Metals can do the mixin.

tgodzik commented 4 days ago

We would need to have separate metals.debug settings section as only things under metals are being sent. We could automatically sync them with the java settings, but not sure if that wouldn't be confusing sometimes.

adpi2 commented 4 days ago

We would need to have separate metals.debug settings section as only things under metals are being sent.

Yes I agree, also because not all the Java settings are supported