Using CodeLLDB as default debuggers for rust

[ClSlaid]

Feature description

lldb-vscode is the vscode-dap wrapped version of lldb, it does embed with pretty print features, making commonly used rust data structures like std::string::String, std::sync::Arc, std::collections::Vec hard to read.

This is an example of the view of &str, all static string in the executable image came out together, too much noise!

Switching to CodeLLDB, that's much usable.

Additional information

I've been using codelldb on my customized branch, but I don't know how to ensure the users will have a local image of codelldb. What I can do is paste my configuration here as an example:

-- lua/modules/tools/dap/dap-lldb.lua

-- other configurations
local codelldb_port = "65472"
dap.adapters.codelldb = {
	type = "server",
	port = codelldb_port,
	executable = {
		command = os.getenv("HOME") .. "/" .. ".local/share/nvim/mason/bin/codelldb", -- installed with mason
		args = { "--port", codelldb_port },
	},
	name = "codelldb",
}
-- copy from cpp with custom type
dap.configurations.rust = {
	{
		name = "Launch",
		type = "codelldb",
		request = "launch",
		program = function()
			return vim.fn.input("Path to executable: ", vim.fn.getcwd() .. "/", "file")
		end,
		cwd = "${workspaceFolder}",
		stopOnEntry = false,
		args = function()
			local input = vim.fn.input("Input args: ")
			return vim.fn.split(input, " ", true)
		end,

		-- if you change `runInTerminal` to true, you might need to change the yama/ptrace_scope setting:
		--
		--    echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
		--
		-- Otherwise you might get the following error:
		--
		--    Error on launch: Failed to attach to the target process
		--
		-- But you should be aware of the implications:
		-- https://www.kernel.org/doc/html/latest/admin-guide/LSM/Yama.html
		runInTerminal = false,
	},
}

-- lua/modules/config/lang/rust-tools.lua

-- other configurations
    dap = {
        adapter = require("nvim-dap").adapters.codelldb,
    }

[ClSlaid]

cc @ayamir if you have time for this, please take a look.

[charliie-dev]

I think it's better to have this in discussions.

[charliie-dev]

cc @ClSlaid

[ClSlaid]

The main problem is that I don't find a way to ensure the installation of codelldb. I've found ensure_install of LSPs, but I don't see any ensure of DAPs.

[charliie-dev]

but there might be some issues with mason-nvim-dap, there some discussion I had with the plugin author.
https://www.reddit.com/r/neovim/comments/1146uy8/comment/j8xboz4/?utm_source=share&utm_medium=web2x&context=3

[ClSlaid]

Are those DAPs that are not conflicted enough for this and future use?

[charliie-dev]

I'm not sure what u mean. Can u elaborate more?

[ClSlaid]

In the context I see some DAPs may have name conflicts. I wonder if we only supported limited number of DAPs with this plugin and waits for future fixes.

[charliie-dev]

aha, didn't know that. I'm not sure about how this plugin handles this kind of conflicts. Maybe ask the plugin author?

[Jint-lzxy]

Great suggestion! I migrated debuggers for languages supported by LLVM to codelldb a few weeks ago, mainly because vscode-lldb cannot be distributed as a separate package on some platforms - users either need to install llvm or need to compile it themselves. We have several issues regarding incorrect installation of vscode-lldb and they could be avoided after switching to codelldb.

The main problem is that I don't find a way to ensure the installation of codelldb.

This shouldn't be a problem. We can include codelldb via vim.api.nvim_command("MasonInstall codelldb"). As codelldb provides debugging support for most commonly used compiled languages, I can't find any reason to prevent installing codelldb during bootstrap.

cc @ClSlaid @ayamir

[ayamir]

We can include codelldb via vim.api.nvim_command("MasonInstall codelldb").

It's ok. How about using https://github.com/jay-babu/mason-nvim-dap.nvim? As we did for lsp.

[charliie-dev]

https://github.com/jay-babu/mason-nvim-dap.nvim/blob/main/lua/mason-nvim-dap/mappings/source.lua

I think it's doable. But we might need upstream support in the future.