[RFC] Rename lldb-vscode to lldb-dap

Subprojects LLDB
1

Hi everyone,

lldb-vscode is a tool build on top of the SB API that implements the Debug Adapter Protocol. Similar to the Language Server Protocol (LSP), it was originally developed for Microsoft Visual Studio Code and is now an open standard. Various IDEs and editors support have added support for it. Rather than tying it to one specific implementation, the utility deserves a more generic name.

I propose we rename the tool from lldb-vscode to lldb-dap and update the name in classes and tests. This change should be largely mechanical. The goal here is not to make it harder to use lldb-dap with Visual Studio Code, so the manifest and installation instructions would remain as they are today, but of course updated for the new name.

Please let me know if you have any concerns. If there’s no objection to this I’ll put up a PR in the coming days.

PS: Yesterday, at the LLVM Dev Meeting, I learned that there is at least one big company that has already renamed the binary internally.

5 Likes
2

Last time I explained it to a colleague, it was confusing to have that extra step. DAP exists and lots of stuff supports it, use this thing named after only one of those editors, but it’ll work in your Emacs somehow I promise.

So I like the idea of the new name.

Also it means folks are less likely (as I did at first) to think there is a build of it available in the VS Code extensions marketplace. lldb-dap is more obviously a thing that would get bundled into something else rather than lldb-vscode which sounds like a thing I can install directly.

1 Like
3

I agree that this would be a more accurate and useful naming scheme.

We should also make sure that we promulgate this change. I still get bug reports from people using lldb-mi in VSCode even though that hasn’t been actively supported for a while now.

4

I’ll chime in as a representative of a big company that’s using it, but hasn’t changed the name. We ship lldb-vscode and use it with vscode. I’m ok with changing the name.

5

I’m 100% in favor of changing the name. Thanks for putting up this RFC!

If/When you make this change, please be sure to add a release note so we can point people to it when we inevitably get bugs about there not being an lldb-vscode binary in their LLDB installation. :smile:

6

There is the option to add a link lldb-vscode -> lldb-dap, and keep the lldb-vscode source folder containing only a readme linking to the new readme location.

Remove them a release or two later.

Whether that benefits anyone or just delays the inevitable confusion, I’m not sure.

7

Certainly the readme for lldb-dap should note its previous name so when folks do find it, they know they’re in the right place.

1 Like
8

+1 over here too.

This sounds good – personally we wouldn’t need it, but I think various release managers might appreciate it.

If we provide this, it would be possible to detect basename(argv[0]) == "lldb-vscode" and print a notice to update your launch.json or whatever config. But that might feel too spammy unless we have a way to rate limit it or let the user nack the message to never see it in the future.

9

I am good with the “lldb-dap” name as well!

10

I’m also good with the change as well!

11

Thanks for the input everyone! As promised, I’ve created the PR: [lldb] Rename lldb-vscode to lldb-dap by JDevlieghere · Pull Request #69264 · llvm/llvm-project · GitHub.

12

Congratulations . BTW Wish lldb-dap would be able to use a local lldb binary just like clangd (for vscode) .

13

I have a question that is unrelated to the topic. What is the difference between lldb-mi and lldb-vscode? Can the former be replaced by the latter? I know that there is a setting for lldb-mi in the CMake Tools plugin in VSCode. Can it be replaced with lldb-vscode?

  "cmake.debugConfig": {
    "MIMode": "lldb",
    "miDebuggerPath": "/usr/bin/lldb-mi",
14

Both are tools for IDEs to interact with lldb but they do so using different protocols. lldb-mi implements the GDB/MI interface while lldb-vscode (lldb-dap) implements the Debug Adapter Protocol. While they serve a similar purpose, they are not interchangeable.

15

Thanks for your reply!

16

@JDevlieghere , after giving this a second thought, wouldn’t it be better to rename the binary to lldb-dap-server? dap is the protocol, and this binary is a server implementation for that protocol. This becomes more visible when writing python tests for the dap server, where there’s clearly a client and server. To give an specific example, there’s a variable in your current PR that is called self.dap, and that would look much cleaner as self.dap_server or self.server.
What do you think?

17

That definitely sounds like an improvement for the tests where the distinction between the server and the client is more important, but I think the -dap suffix is obvious enough for the binary itself, similar to how other LSP implementations end with -lsp.

18

Sounds good :slight_smile:

19

Awesome, I’ll update the PR!

20

While I agree it’s a better name, this is going to cause some collateral damage in the swift toolchain and swift-server/vscode-swift due to the name being used already. Can you please sync with Adam and ensure that this gets pulled into Swift 5.10 as well off you do the rename?