LLDB adapter setup issue

[BirdeeHub]

Have you read the docs and searched existing issues?

• I have read the README's troubleshooting guide and FAQ(https://github.com/mrcjkb/rustaceanvim?tab=readme-ov-file#left_speech_bubble-faq).
• I am using the latest rustaceanvim release.
• I have searched existing issues.
• I have searched existing discussions.
• I have searched the existing issues of other plugins related to this issue (if applicable).
• I have searched the existing rust-analyzer issues (if applicable).
• I can reproduce the issue with stable Neovim (not a distribution or nightly) and the minimal config.
• This is an issue about rustaceanvim, not rust-analyzer or Neovim.
• This is not an issue with autocompletion.

Neovim version (nvim -v)

0.10.4

Operating system/version

NixOS unstable

Output of :checkhealth rustaceanvim

==============================================================================
rustaceanvim: require("rustaceanvim.health").check()

Checking for Lua dependencies ~
- OK [mfussenegger/nvim-dap](https://github.com/mfussenegger/nvim-dap) installed.

Checking external dependencies ~
- OK rust-analyzer: found rust-analyzer 1.86.0-nightly (4a43094 2025-02-02)
- OK Cargo: found cargo 1.86.0-nightly (0e3d73849 2025-02-01)
- OK rustc: found rustc 1.86.0-nightly (4a4309466 2025-02-02)
- OK lldb: found lldb version 19.1.6

Checking config ~
- OK No errors found in config.

Checking for conflicting plugins ~
- OK No conflicting plugins detected.

Checking for tree-sitter parser ~
- OK tree-sitter parser for Rust detected.

How to reproduce the issue

install lldb-dap or codelldb to path instead of via mason and try to run a debugger.

Observe it try to find the executable in the current directory rather than the PATH

Expected behaviour

I expect it to run the thing found in my path rather then trying to search the current working directory for "lldb-dap"

Unfortunately, because command field of the adapter is just the name of the command, it tries to look in the current directory for it.

I will be making a PR to make it call vim.fn.exepath while setting up the adapter, which solves the issue.

Actual behaviour

Error executing vim.schedule lua callback: Vim:E475: Invalid value for argument cmd: '/home/birdee/Projects/ode/lldb-dap' is not executable
stack traceback:
[C]: in function 'jobstart'
...r/pack/myNeovimPackages/opt/nvim-dap/lua/dap/session.lua:300: in function 'handler'
...r/pack/myNeovimPackages/opt/nvim-dap/lua/dap/session.lua:1115: in function 'handle_body'
...r/pack/myNeovimPackages/opt/nvim-dap/lua/dap/session.lua:1619: in function ''
vim/_editor.lua: in function <vim/_editor.lua:0>

The minimal config used to reproduce this issue.

I installed these to PATH via nix

        inputs.fenix.packages.${system}.latest.toolchain
        rustup
        llvmPackages.bintools
        lldb


I installed rustaceanvim as a plugin in pack/*/start

I didnt perform any other setup steps for rustaceanvim or rust in general.

[mrcjkb]

Hey 👋

thanks for pointing this out. The config.internal module has a exepath_or_binary that you can use.
It falls back to the executable name if exepath returns an empty string.

[BirdeeHub]

exepath is not returning an empty string though.

exepath is returning the correct location.

In the adapter setup right above my changes in my PR it checks to make sure vim.fn.executable is true also, so in that scenario we know exepath will not return people an empty string if that check passes

[BirdeeHub]

OOOOH i didnt understand what you meant by "you can use" I thought you meant "in your config" and not "in the PR". Yes definitely, good idea, I didnt see that. Its technically already checked right above by vim.fn.executable, but you never know, good to be safe.

[xarvex]

Just wanted to say thank you for spotting and fixing this issue, I was wondering why codelldb was not being configured! (Also NixOS)

All works as expected now, cheers!

[BirdeeHub]

Yeah I finally got around to wanting to use my debugger for rust (I keep meaning to use them more and never do) and noticed the odd path in the error and was like

"why is it looking in the current directory but checkhealth says it can find it?"

:lua print(vim.inspect(require('dap').adapters.lldb))

"yup. Its just the name, lets try absolute path"

:lua require('dap').adapters.lldb.command = vim.fn.exepath('lldb-dap')

"alright nice that works, time to grep for lldb-dap and find where that gets set"

Was an easy fix I just had to put my mind to it. I only sorta know how debuggers work. I barely even know how to use them when they ARE set up, been meaning to improve at it.

mrcjkb is the one who deserves credit here for putting the time in reading the docs to put something like this plugin together.