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

[seantrow]

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:

• Operating system: Windows (not OS specific)
• VSCode version: 1.93.0
• VSCode extension version: 1.39.0
• Metals version: 1.3.5

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]

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]

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]

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]

@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]

@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]

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]

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