How do I Start Debugging from a module file?

[LukeFranceschini]

I'm pretty new to neovim and rust, so if I'm asking in the wrong place and you think this is a question for rust-analyzer (or even just rust/cargo in general) just let me know! Thanks in advance for your help <3

I installed codelldb manually and use Lazy to install rustaceanvim, nvim-dap, and nvim-dapui, and when I run RustLsp debuggables from main.rs I get a menu that lets me pick a build and it works and I can debug interactively perfectly well. However, when I try to do this from a module file the debuggables list only includes a test option, and not a build one which is what I want. I can set a breakpoint in the module, open main.rs in another buffer, start the debugger there, and it will properly break in the module. It would just be nice to be able to run the debugger straight from the other module. So there is a workaround I can use (and probably automate through a keymap somehow) but I was just wondering if there was a better way to do this.

For context, here is what the relevant parts of my files look like:
lint-testing/src/main.rs

mod my_mod;
fn main() {
    my_mod::test_print();
}

lint-testing/src/my_mod.rs

pub fn test_print() {
    println!("test_print in module my_mod has been called");
}

and when I run RustLsp debuggables from lint-testing/src/main.rs (there is a test in main.rs):

Debuggables
1: build --package lint-testing --bin lint-testing
2: test --no-run --package lint-testing --all-targets

and finally RustLsp debuggables from lint-testing/src/my_mod.rs:

Debuggables
1: test --no-run --package lint-testing --all-targets

I thought that maybe I needed to tell cargo about the build explicitly so that rust-analyzer would pick it up even if I was in a different file, but when I add the below to Cargo.toml it makes RustLsp debuggables just exit silently even if I'm in main.rs. I don't get a menu or anything to choose from. This at least indicates that rust-analyzer is looking at cargo and picking up changes from there though.

[[bin]]
name = "main"
path = "src/main.rs"

It's also possible I'm misconfiguring something, so here are the relevant parts of my init.lua:

local plugins = {
    {
        -- this will use clippy by default if it's installed (rustup component add clippy)
        "mrcjkb/rustaceanvim",
        version = "^4",
        ft = { "rust" },
    },
    { "mfussenegger/nvim-dap" },
    {
        "rcarriga/nvim-dap-ui",
        opts = {
            -- SNIP 
        },
        config = function(_, opts)
            require("dapui").setup(opts)
        end,
    },
}
require("lazy").setup(plugins, opts)

local codelldb_extension_path = vim.env.HOME .. "/.vscode/extensions/vadimcn.vscode-lldb/extension/"
local codelldb_path = codelldb_extension_path .. 'adapter/codelldb'
vim.g.rustaceanvim = {
    dap = {
        autoload_configurations = true,
        adapter = require('rustaceanvim.config').get_codelldb_adapter(
            codelldb_path,
            codelldb_extension_path .. 'lldb/lib/liblldb.so'
        ),
    },
}
local dap = require("dap")
dap.adapters.codelldb = {
    type = 'server',
    port = "${port}",
    executable = {
        command = codelldb_path,
        args = {"--port", "${port}"},
    }
}
dap.configurations.rust = {
    {
        type = 'codelldb',
        request = 'launch',
        program = function()
            -- TODO should this read project settings from rust-analyzer/cargo?
            -- For now, just error if we try to ask nvim-dap to launch the debugger instead of RustLsp! debuggables
            error("Use ':RustLsp! debuggables' to launch the debugger (<leader>r on Luke's system)")
            return dap.ABORT
        end,
        terminal = 'integrated',
        sourceLanguages = { 'rust' },
        showDisassembly = "never",
    }
}

If I'm configuring something incorrectly or non-idiomatically please let me know.
In summary, I'm trying to get the debuggables list and start the debugger from a module file. If the answer is, open main.rs in another buffer and launch the debugger from there then that's fine, I just figured I would double check if there was a more convenient way. Thanks!

[LukeFranceschini]

Oh and in case it matters, my neovim version

NVIM v0.9.5
Build type: Release
LuaJIT 2.1.1692716794

and :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 0.3.1868-standalone
- OK Cargo: found cargo 1.76.0 (c84b36747 2024-01-18)
- OK rustc: found rustc 1.76.0 (07dca489a 2024-02-04)
- OK debug adapter: found codelldb

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.

[mrcjkb]

Hey 👋

RustLsp debuggables delegates to a rust-analyzer feature (rust-analyzer/runnables), and it only
works with the module you're currently in.

However, rustaceanvim will by default run the command whenever you open a module, and register them with nvim-dap.
So the debug configurations for modules you have previously opened should show up when you run :DapContinue, even after you leave the module.
Because rust-analyzer can take a very long time to finish initialising, people have had varying degrees of success with this.

I don't think it's likely that rust-analyzer will implement the feature as you describe it, because it could
potentially lead to too many choices showing up in large projects.

But rustaceanvim does support loading project-specific debug configurations using :h dap-launch.json.

Regarging your config:

I can't see anything wrong with it. You shouldn't need to configure dap.adapters.codelldb or dap.configurations.rust manually. rustaceanvim does that for you 😄

[LukeFranceschini]

Oh if I remove the dap configuration, when I run DapContinue in my_mod.rs I get the following error:

No configuration found for `rust`. You need to ad configs to `dap.configurations.rust` (See `:h dap-configuration`)

I added the manual configuration because I thought that rustaceanvim wasn't configuring dap. Now that I've removed the manual dap configuration I can see that rustaceanvim does configure dap, but only if I open main.rs, or bin/another-binary.rs and not if I open my_mod.rs. I'm not sure if that's intentional, as rust-analyzer/runnables does have a target here when I manually configure dap (test --no-run --package lint-testing --all-targets) which comes up when I run RustLsp debuggables.

After further testing, I learned that if I add a simple test to my_mod.rs then rustaceanvim does configure dap, even for a module. It seems to specifically not configure dap when there is no test. Maybe this has something to do with the fact that RustLsp debuggables always has one more entry (the all-targets one) than DapContinue?

(I understand that rustaceanvim has to wait for rust-analyzer to initialize before it configures dap, but in this case even if I wait for a very long time it never configures dap whereas it normally only takes like, one second. So I think it's actually just not configuring in this case, although if there's a way to double check whether or not rust-analyzer is still actively working I'd be happy to check whether or not that's the case here. I took a look using htop and it doesn't look like rust-analyzer is doing anything different after the first second or two regardless of if I have the test in my_mod.rs or not)

[mrcjkb]

Hmm, that's an interesting insight. But very strange.

rustaceanvim uses the same logic for finding runnables to add nvim-dap debug configurations as it does for :RustLst debuggables:

nvim-dap configurations:

rustaceanvim/lua/rustaceanvim/commands/debuggables.lua

Line 159 in 69a22c2

function M.add_dap_debuggables()

debuggables command:

rustaceanvim/lua/rustaceanvim/commands/debuggables.lua

Line 152 in 69a22c2

runnables_request(mk_handler(function(debuggables)

The shared logic filters results for configurations that aren't cargo check commands:

rustaceanvim/lua/rustaceanvim/commands/debuggables.lua

Line 53 in 69a22c2

local is_not_cargo_check = args.cargoArgs[1] ~= 'check'

I don't see how the --all-targets runnable could be filtered out in one case, but not filtered out in the other, unless it's not provided by rust-analyzer in its response.
My best guess right now is that it's a timing issue (since typing out :RustLsp debuggables takes longer than it does for the callback to be invoked).

I'm away from my laptop right now, but maybe I can play around with deferring the callback invocation somehow.

[mrcjkb]

I've opened an issue for this: #301

[mrcjkb]

I'm not sure if that's intentional, as rust-analyzer/runnables does have a target here when I manually configure dap (test --no-run --package lint-testing --all-targets) which comes up when I run RustLsp debuggables.

After debugging this to little avail, I just realised: test --no-run --package lint-testing --all-targets is not a debuggable target. rust-analyzer/runnables gives you all runnable targets, but not all of them can be debugged with nvim-dap.

That being said, deferring the call did increase the reliability somewhat.

[LukeFranceschini]

Ah okay, so I can ignore that runnable since it wouldn't work with the debugger anyways. I just tried the latest commit (597c8d6) and dap still doesn't get configured when I open up src/my_mod.rs. Even if I manually modify line 166 in debuggables.lua to wait for like 10 seconds, dap is still not configured unless I add a test to the file. I'm pretty sure rust-analyzer is finished initializing by this point as I can see the all-targets option when I run RustLsp! debuggables. Just to double check, is the intention that rustaceanvim won't configure dap unless rust-analyzer gives a runnable that is also debuggable? Or is it intended to configure dap no matter what when I open up a .rs file?
Maybe I should be manually calling the relevant rustaceanvim function to configure dap? That way I would be able to use the correct configuration that is provided by rustaceanvim while still being able to debug a module while running the main binary instead of only being able to debug a module with a test.

On a side note, I tried using a launch.json as you mentioned upthread, and it appears in the list of options when I run DapContinue but it doesn't have the nice feature that RustLsp! debuggables has where it actually runs cargo build before starting the debugger so that the executable has the latest changes in the file. It also doesn't have the "bang" feature that RustLsp! does where it remembers the previous choice. It's possible I've misconfigured something, here is what I have in .vscode/launch.json:

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "codelldb",
            "request": "launch",
            "name": "Debug Rust",
            "program": "target/debug/lint-testing",
            "cargo": {
                "args": ["build"]
            }
        }
    ]
}

[mrcjkb]

Even if I manually modify line 166 in debuggables.lua to wait for like 10 seconds, dap is still not configured unless I add a test to the file.

Could you please point me to a file in a cargo project in a GitHub repo or gist that I can use to try this out?

🤔 Maybe rustaceanvim is adding the configuration, but nvim-dap isn't picking it up?

Just to double check, is the intention that rustaceanvim won't configure dap unless rust-analyzer gives a runnable that is also debuggable?

Yes. It wouldn't make sense to try to debug things that can't be debugged.

Maybe I should be manually calling the relevant rustaceanvim function to configure dap?

Rustaceanvim doesn't provide a function as part of its public API (i.e. if you use it, I can't guarantee you that it won't be moved, renamed, or change its signature between minor version bumps).
But I don't think that's the way to go anyway. That's what .vscode/launch.json is for.

I run DapContinue but it doesn't have the nice feature that RustLsp! debuggables has

That's because DapContinue is an nvim-dap command, not a rustaceanvim one.

You can also use .vscode/launch.json with :RustLsp debuggables, so I would recommend just to use that.
If you don't want to use separate commands, you could set up a keymap, something like this:

vim.keymap.set("n", "<leader>dc", function()
  -- will fail if there is no rust-analyzer client
  local success = pcall(vim.cmd.RustLsp, "debuggables")
  if not success then
    vim.cmd.DapContinue()
  end
end)

[LukeFranceschini]

Okay so after some playing around I realized that this only happens if there is another binary. I set up an simple example cargo project at https://github.com/l3france/rustaceanvim-dap-configuration
Dap does not get configured when I open src/my_mod.rs in that project, but if you remove src/bin/other.rs (and it's reference in Cargo.toml) then it does get configured. At first I thought that maybe rust-analyzer was getting confused and couldn't select a binary to build. But even if I add Cargo.toml entries for the two binaries it doesn't work. It's very possible I'm configuring the project wrong in Cargo.toml and that's why it's breaking, I'm new to cargo.
I also found that even if dap is configured properly, when I run DapContinue from src/my_mod.rs the breakpoint I set in there is rejected. I'm not really sure why this happens, because I can see the dapui flash open momentarily and then immediately close, so I think it's running the program and just skipping that breakpoint for some reason. Most online resources indicate this happens when you build without debug symbols, but target/ only has a folder for debug so I don't think that's the issue here.
Anyway, while I was looking at this I realized that there was a different solution I could try. Since rustaceanvim will remember the debuggables for buffers you had open previously, we can search for main.rs, jump to it and run the command there, then jump back. I added the following to a hotkey to do this and it seems to do what I want. This is probably pretty brittle and breaks when something else has src/main.rs open or if you're working on a project with a different structure, but for now it works for me.

-- rustaceanvim uses rust-analyzer to find the list of possible targets to debug, but rust-analyzer
-- only returns targets for the current file. Since I mostly work on binaries with library modules
-- in the same project, go to main.rs, start the debugger, and then come back to the current module.
function debug_rust_main(bang)
    local main_rs_path = vim.fn.findfile("main.rs", ".;")
    local current_path = vim.fn.expand('%')
    if main_rs_path == "" then
        error("Could not find main.rs in debug_rust_main()")
        return
    end

    vim.cmd("edit " .. main_rs_path)
    if bang then
        vim.cmd("RustLsp! debuggables")
    else
        vim.cmd("RustLsp debuggables")
    end
    vim.cmd("edit " .. current_path)
end

[mrcjkb]

🤔 cargo workspaces might solve your problem.

[LukeFranceschini]

Workspaces might help with the issue of multiple binaries confusing the dap initialization, but I don't actually need or want multiple binaries. I was just doing this in a simple "test" package where I was trying out various rust and editor features. So for my actually projects (where I almost always will have only one binary) it should work fine, and the snippet I posted above to start the debugger with the whole binary will work for me when I'm in a module or submodule.
Thanks for all your help with this, I know I meandered around quite a bit so thanks for your patience. I hope you have a good one! <3