DAP lldb doesn't register... nor some of the plugin functionality

[ArcusCerebellumus]

I have the codelldb package from Mason (which by itself, as a CLI, works just fine - I'm using it as it is for now), but my client doesn't seem to know what to do with it. The "LLDB: Launch" option doesn't get command filled in (i.e. path to executable), and despite the option clearly saying "LLDB" the id is "cppdbg":

...a/Local/nvim-rust-data/lazy/nvim-dap/lua/dap/session.lua:1419: adapter.command must not be empty. Got: {
  command = "",
  id = "cppdbg",
  options = {
    detached = false
  },
  type = "executable"
}
stack traceback:
...

(as you can infer from paths here - I'm on Windows)
another trace I got by trying different options is... I couldn't figure it out (or rather I didn't want to figure out the inner workings of dap just yet, in case the fix is simple):

...a/Local/nvim-rust-data/lazy/nvim-dap/lua/dap/session.lua:1187: ENOENT: no such file or directory
stack traceback:
...

...I assume it fails for similar reasons since there are some older posts here with similar symptoms for which manually fixing paths to lib and exec seems to help.

So, I gave it an honest attempt and tried manual pathing - it barely made a dent in my understanding of what's going on, if not worse - broke everything:

local codelldb_path = ...
local liblldb_path = ...
vim.g.rustaceanvim = {
    dap = {
        adapter = require 'rustaceanvim.config'.get_codelldb_adapter(codelldb_path, liblldb_path)
    },
} 

This makes the config crash, because the field I'm setting doesn't exist (yet), but if I put it in a function - it's fine. The principal of the thing stays the same. Options remain as they were, errors too...

There's also one other weirdness going on:
In the Commands section of help everything "revolves" around :RustLsp! command, but it doesn't seem to be present in my client despite Lsp being clearly attached and showing all the expected goodies like code actions and cmp...

I have a separate NVIM_APPNAME that does no lspconfig for rust, since I really want to try this plugin out.

If you require more context - I will be happy to produce it. Please help.

[mrcjkb]

Hey 👋

If the RustLsp command isn't available, but there's an LSP client attached, it's not the rustaceanvim client. It's probably the one set up by nvim-lspconfig.

My guess would be that you've used mason-lspconfig.nvim to install rust-analyzer. That plugin assumes you're using nvim-lspconfig and sets it up for you, resulting in a conflict with this plugin.
I try to detect this in the health checks (:checkhealth rustaceanvim).
See also: #94

This plugin supports getting codelldb from mason.nvim automatically, but not rust-analyzer. The reason is that the mason rust-analyzer installation is usually built with a different toolchain than your project, which can lead to inconsistencies and subtle bugs. So I recommend using rustup or nix instead.
If you want rustaceanvim to use a mason.nvim installation anyway, you may have to configure it manually.
If rustaceanvim doesn't find rust-analyzer on the PATH, or you haven't set the command manually, it won't start up the LSP client.

[ArcusCerebellumus]

You're right - it WAS pulling it from Mason, but my current ...'mason-lspconfig'.setup(... only sets up lua_ls, AFAIK :.... does it do something else by default even if I don't specify any other servers?

I tried removing the setup function entirely, but this just leads to rust_analizer not starting at all - even with :RustAnalyzer start.

Do I have to provide a path to rustup version of it inside vim.g.rustacionvim manually too? I thought it was supposed to be automatic... :|

[ArcusCerebellumus]

Also, I managed to run the debuger like this:

    {
        'mrcjkb/rustaceanvim',
        version = '^4',
        ft = { 'rust' },
        config = function()
            local dap_cmd = 'C:/Users/Arcus/AppData/Local/nvim-rust-data/mason/bin/codelldb.cmd'
            -- local dap_cmd = 'C:/Users/Arcus/AppData/Local/nvim-rust-data/mason/packages/codelldb/extension/adapter/codelldb.exe'

            ---@type RustaceanOpts
            vim.g.rustaceanvim = {
                ---@type RustaceanDapOpts
                dap = {
                    ---@type DapExecutableConfig
                    adapter = {
                        type = 'executable',
                        -- args = {''},
                        name = 'codelldb',
                        command = dap_cmd
                    }
                },
            }
        end
    },

But it only works once and then fails again with error in sessions.lua, until I "stir" options to produce the exact same result, but in different words (thus commented path to actual exe instead of cmd proxy)

[mrcjkb]

You're right - it WAS pulling it from Mason, but my current ...'mason-lspconfig'.setup(... only sets up lua_ls, AFAIK :.... does it do something else by default even if I don't specify any other servers?

I tried removing the setup function entirely, but this just leads to rust_analizer not starting at all - even with :RustAnalyzer start.

I don't use mason.nvim myself, so I all I know about it is based on what others have reported to me.
But the fact that the LSP client doesn't start at all if you remove the mason setup function makes me think it's been setting it up for you. rustaceanvim's client is called rust-analyzer, and the lspconfig client is called rust_analyzer (with an underscore). You can also detect if the lspconfig client has been set up by running :checkhealth rustaceanvim.

Do I have to provide a path to rustup version of it inside vim.g.rustacionvim manually too? I thought it was supposed to be automatic... :|

Normally, it should be automatic. But only if neovim can find it on the PATH (again, you can check this with :checkhealth rustaceanvim.

Additionally, make sure there aren't any errors (e.g. from filetype autocommands or other plugins) preventing rustaceanvim from initializing (see the troubleshooting section of the readme).

[ArcusCerebellumus]

I figured out that rust-analizer in ~\.cargo\bin was the wrong version for my toolchain. I have no idea how this happened since it wasn't touched in a couple of months - after a fresh install no less.

So, doing rustup component add rust-analyzer fixed the issue: now I have all of the plugin commands available... as to what's up with the Debugger - I've yet to check. Will keep you posted.

[ArcusCerebellumus]

Update.

The compiler "issue" I was having turned out to be something embarrassingly simple and stupid, but for posterity, I will try to explain it without getting too red in the face.

It turns out that someone of the involved "bookey" of software (be it Cargo, or LLDB, or LSP, or Neovim itself, or whatever else) keeps track of the last compile time and last save time (presumably by checking file metadata) for every source and bin, and if the source is "younger" then the binary it REFUSES to start Debugging with this message:

...session.lua:1187: ENOENT: no such file or directory

where the "file" refers to the source of the binary - not the Debugger... nice choice of words for the trace, what can I say... So, in my eagerness to see it working, I kept hammering :w after every little action taken thus setting off that blasted check. And since I was compiling from the same terminal, quitting and then restarting Vim every time, this kept happening over and over.

LLDB should have a pre-run argument and if so - I should figure out how to pass it cargo build to avoid stepping on that rake in the future.

[mrcjkb]

Thanks for the update.

ENOENT: no such file or directory is indeed thrown by the vim.system API call (presumably called by nvim-dap in this case) when it can't find the binary or command.

Are you using nvim-dap's DapContinue or rustaceanvim's RustLsp debuggables command? The latter compiles a debug build before entering a debug session.