unable to debug tests with dap.

[1024bees]

Hey folks,

I'm trying to integrate nvim-dap with rust-tools and I'm having some issues. the ideal UX i'm going for is being able to launch a particular test under gdb or rr from neovim.

my relevant config files are

• my rust tools configuration at: https://github.com/1024bees/dotfiles/blob/work2/nvim/lua/lib/plugin/lspconfig.lua
• my dap configuration at: https://github.com/1024bees/dotfiles/blob/work2/nvim/lua/lib/plugin/dap.lua to pull out the meaningful bits, my config looks like

-- rust tools configuration
local rt = require("rust-tools")

rt.setup({
  server = {
    on_attach = function(client, bufnr)
      on_attach(client, bufnr)
      vim.keymap.set("n", "A", rt.code_action_group.code_action_group, { buffer = bufnr })
    end,
    capabilities = capabilities,
    settings = {
      ["rust-analyzer"] = {
        assist = {
          importMergeBehaviour = "full",
          importPrefix = "plain",
        },

        callInfo = {
          full = true,
        },

        cargo = {
          loadOutDirsFromCheck = true,
        },

        checkOnSave = {
          --allFeatures = true,
        },

        procMacro = {
          enable = true,
        },
        diagnostics = {
          enable = true,
          disabled = { "unresolved-proc-macro" },
          enableExperimental = true,
          warningsAsHint = {},
        },
      },
    },
  },

  dap = {
    adapter = {
      type = "executable",
      command = "lldb-vscode-10",
      name = "rt_lldb",
    },
  },
})

-- dap configuration 
local dap = require("dap")
dap.adapters.lldb = {
  type = "executable",
  command = "/usr/bin/lldb-vscode-10", -- adjust as needed, must be absolute path
  name = "lldb",
}

dap.configurations.cpp = {
  {
    name = "Launch",
    type = "lldb",
    request = "launch",
    program = function()
      return vim.fn.input("Path to executable: ", vim.fn.getcwd() .. "/", "file")
    end,
    cwd = "${workspaceFolder}",
    stopOnEntry = false,
    args = {},

    -- 💀
    -- if you change `runInTerminal` to true, you might need to change the yama/ptrace_scope setting:
    --
    --    echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
    --
    -- Otherwise you might get the following error:
    --
    --    Error on launch: Failed to attach to the target process
    --
    -- But you should be aware of the implications:
    -- https://www.kernel.org/doc/html/latest/admin-guide/LSM/Yama.html
    -- runInTerminal = false,
  },
}

-- If you want to use this for Rust and C, add something like this:

dap.configurations.c = dap.configurations.cpp
--dap.configurations.rust = dap.configurations.cpp

I've tried two paths thus far:

1. using the :RustDebuggables path.
2. using code actions to pull up the run / debug action

Reproduction

Consider the minimal library crate with one test:

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn it_works() {
        let result = add(2, 2);
        assert_eq!(result, 4);
    }
}

Invoking RustDebuggables

When I invoke RustDebuggables with the above code, I am greeted by three options:

Debuggables                                                                                  
1: test --no-run --package exampletools --lib -- tests --nocapture
2: test --no-run --package exampletools --lib -- tests::it_works --exact --nocapture
3: test --no-run --package exampletools --all-targets

if I select any of these options, the following text comes up:

compiling a debug build for debugging. This might take some time...
Press ENTER or type command to continue

If i press enter, regardless of the amount of time that I wait for a debug build to be compiled, the error

No compilation artifacts

is always emitted

Using code actions

If I try to bring up code actions for the it_works test, I am only given the option for a singular action: Generate a documentation template

Notes

FWIW, I can use the :RustTest and :RustRunnables command to run commands and tests with no issue.

Has anyone seen this before? I'll use this as a tracking issue as I tinker around.

[igorlfs]

Hey, I'm also having this issue. I believe this bug was introduced yesterday, as debuggables had a refactor, and I wasn't having this issue prior.

[1024bees]

@igorlfs how did you launch off dap on cargo test targets before this change?

I'd like to understand how dap is typically launched with this plugin. How did you launch a debug session under dap prior to these recent changes?

The only example I saw was in the README, where it looks like there is a code action to start a debug session under dap.

[igorlfs]

The only example I saw was in the README, where it looks like there is a code action to start a debug session under dap.

Yeah, that's pretty much how it works. You should map rt.hover_actions.hover_actions to something, go to the test definition and then select Debug. You can also use :RustDebuggables but I don't find it as practical.

I'd like to understand how dap is typically launched with this plugin. How did you launch a debug session under dap prior to these recent changes?

I'm using codelldb installed via Mason and configured according to nvim-dap's wiki. Since I'm using Mason, which sets up codelldb in my path, my adapter configuration looks like the following:

{
    type = "server",
    port = "${port}",
    executable = {
        command = "codelldb",
        args = { "--port", "${port}" },
    },
}

And my rust-tools config is:

require("rust-tools").setup({
    server = {
        ...
    },
    tools = {
        hover_actions = {
            auto_focus = true, -- eases hover_actions' usage
        },
    },
    dap = {
        adapter = {
            -- my codelldb adapter
        }
    },
})

[simrat39]

Fixed in #327