lldb-vscode has been renamed to lldb-dap

[helmesjo]

Summary

LLVM v18.0.0 changed the name of the "LLDB Debug Adapter Protocol" executable from lldb-vscode to lldb-dap and thus isn't found by helix:

$ hx --health cpp
Configured language servers:
  ✓ clangd: C:\Program Files\LLVM\bin\clangd.exe
Configured debug adapter: lldb-vscode
Binary for debug adapter: 'lldb-vscode' not found in $PATH
Highlight queries: ✓
Textobject queries: ✓
Indent queries: ✓

After creating a symlink named lldb-vscode.exe (on windows atm) it works again:

$ hx --health cpp
  ✓ clangd: C:\Program Files\LLVM\bin\clangd.exe
Configured debug adapter: lldb-vscode
Binary for debug adapter: C:\Program Files\LLVM\bin\lldb-vscode.exe
Highlight queries: ✓
Textobject queries: ✓
Indent queries: ✓

Reproduction Steps

1. Install LLVM v18+ (eg. winget install LLVM.LLVM) and make sure the bin dir is in PATH.
2. Run hx --health cpp and see that it can't find debug adapter.
3. Create symlink lldb-vscode -> lldb-dap.
4. hx --health cpp now shows it as found.

Platform

Windows

Terminal Emulator

alacritty 0.13.1 (fe2a3c5)

Installation Method

winget install Helix.Helix

Helix Version

helix-term 23.10 (f6021dd)

[David-Else]

The only reference to the filename I can find is in languages.toml:

[language.debugger]
name = "lldb-vscode"

There is no facility to add any OR statements here. Maybe the user needs to create a symbolic link, instructions could be added now to the WIKI https://github.com/helix-editor/helix/wiki/Debugger-Configurations

Maybe we should switch to lldb-dap now and ask users to symlink the old file name?

[helmesjo]

Yeah expecting the new name seems correct IMO. I assume name doesn't support any pattern matching?

[David-Else]

@the-mikedavis Do you think we should change all the references to lldb-dap now to be future proof? It seems more correct to use the current naming, even though the majority of users (if there are many) would need to make a symlink as they will be using older lldb-vscode versions (for a while).

[the-mikedavis]

Yep that makes sense to me. Having to symlink the binary or add an entry to languages.toml is not too bad of a workaround for older lldb installations