[lldb-dap] global `initCommands` settings for vscode extension

[eronnen]

It would be nice to have a global vscode setting for initCommands that can be set in the workpsace/user scope, so that it will be possible to declare common init commands like loading init script or data formatters without copying it to every launch configuration.

In case there are init commands both in the global scope and in the launch configuration it seems reasonable to run the global commands first and then the launch commands

[llvmbot]

@llvm/issue-subscribers-lldb-dap

Author: Ely Ronnen (eronnen)

It would be nice to have a global vscode setting for `initCommands` that can be set in the workpsace/user scope, so that it will be possible to declare common init commands like loading init script or data formatters without copying it to every launch configuration.

In case there are init commands both in the global scope and in the launch configuration it seems reasonable to run the global commands first and then the launch commands

[ashgti]

lldb-dap does load the user init (e.g. ~/.lldbinit) if you want to set your settings there.

The ~/.lldbinit is also used for for the lldb CLI as well, so its not lldb-dap specific, but it is one option.

In the extension, we could add a setting for additional init settings, but one issue is what do you do when a launch.json configuration also has an initCommands specified? Do we append them? Do they go first or last? Its hard to tell what the right solution is.

You can put your launch.json configuration in a .code-workspace file as well, so its possible for you to share launch configurations there or in a per-folder .vscode/launch.json file.

[eronnen]

Maybe initCommands is too specific, but the use case I'm trying to address is that I have a project with many launch configurations, and I have to copy my basic settings to each one, for example I always use

"commandEscapePrefix": "",
"initCommands": [
    "command script import ~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/etc/lldb_lookup.py",
    "command source ~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/etc/lldb_commands",
],
"customThreadFormat": "#${thread.index}",
"displayExtendedBacktrace": true,

and it's a lot of configurations to copy to every new launch configuration.

I think it could makes sense to allow these configurations in the workspace level. I agree the behavior could be a bit tricky when we need to combine settings from multiple places, but we can implement merge/precedence rules similar to general VScode configs which can appear workspace/user/language settings files: https://code.visualstudio.com/docs/configure/settings#_settings-precedence

[ashgti]

We could pull more defaults into CLI args and let you specify those as additional lldb-dap args

llvm-project/lldb/tools/lldb-dap/src-ts/debug-adapter-factory.ts

Lines 126 to 135 in 93705c3

	/**
	* Retrieves the arguments that will be provided to lldb-dap either from settings or the provided
	* {@link vscode.DebugConfiguration}.
	*
	* @param workspaceFolder The {@link vscode.WorkspaceFolder} that the debug session will be launched within
	* @param configuration The {@link vscode.DebugConfiguration} that will be launched
	* @throws An {@link ErrorWithNotification} if something went wrong
	* @returns The arguments that will be provided to lldb-dap
	*/
	async function getDAPArguments(

For example, you could use --repl-mode=command instead of "commandEscapePrefix": "", and --pre-init-command 'script import ...'. That is a little tedious though. We could make those into user settings in the extension and convert them into CLI args when we launch the binary.

That may be a reasonable way to set multiple defaults and not have to repeat things.

[eronnen]

But if the same config appears both in the command line and in the launch configuration we still need to define precedence rules... 😅