Automatic configuration for rust projects.

[appetrosyan]

I came across this package as an alternative to dap-mode, and while I feel that it has some potential, it is not usable for me.

The main problem is that it is not possible to set up debugging for Rust projects without significant tinkering. For example, suppose I wanted to debug a specific function in a pure Rust project (best case scenario, most of mine are not pure Rust).

I get the prompt that asks for the project cwd, and the executable. I get a command-line that contains what I can only describe as DIY debug configuration.

Most of it has to be changed, because it doesn't make use of either projection-multi-dape, which may be a configuration issue, (as a consequence of poor UX, and insufficiently detailed documentation).

The mechanism on offer, to use the Emacs built-in variable system is also quite problematic, because that would either opt everyone on the team to the same variables (and annoying prompts), or require me to store the debug configuration separately and share it with people on the team that use Emacs.

So it would be nice if it were possible to not have to specify the fairly standard elements of a debug configuration for a Rust project every time I want to run dape in a new project.

[kavirajk]

The main problem is that it is not possible to set up debugging for Rust projects without significant tinkering

@appetrosyan curious if you manage to make it work?

I'm on the same boat. The problem is I couldn't change those config variables after M-x dape. Not enough docs or Wiki on how to make it work.

[appetrosyan]

I figured out 20% of the problem. It has mostly to do with the differences between LSP mode, DAP mode and eglot. Specifically, that eglot doesn't support code leneses, means that you cannot debug a test, because the LSP doesn't give you that info.

[svaante]

Sorry for taking such a long time responding.

First off, I am unfamiliar with projection-multi-dape so can't help you there.

The mechanism on offer, to use the Emacs built-in variable system is also quite problematic, because that would either opt everyone on the team to the same variables (and annoying prompts), or require me to store the debug configuration separately and share it with people on the team that use Emacs.

This is by design, I don't intend packaging dape with vscode integration. Writing an dape integration with launch.json would be quite trivial, but it's not something I intend to do.

dapes default configurations for rust are a bit lacking, the default :program function for codelldb-rust and lldb-dap could be improved (contributions are welcome).

But debugging an rust compiled binary with those configurations is as simple as:

M-x dape

codelldb-rust :program "path/to/binary"
or with compile
codelldb-rust :program "path/to/binary" compile "cargo build"

Currently there are no specialized unit test configurations for any language package with dape, for now they are delegated to the wiki (feel free to contribute) or external packages.

[appetrosyan]

Alright. I had higher expectations, but in the future, it is considered polite to ask the participants in the discussion whether it's a good idea to move to a discussion out of an issue. As it stands the issue is not particularly helpful to anyone, because it is closed as completed, when a more accurate description would be that it is not planned.

Additionally, on the off chance that this comment might be posted on the issue, I would like to correct you, as I think I've done a poor job of communicating the problem.

codelldb-rust :program "path/to/binary"

This is incorrect for two reasons. 1) because it doesn't work in all cases. 2) because path/to/binary is something that can be requested from rust-analyzer via eglot. To start the process I would need an issue here, so I could reference that and add the necessary patches to eglot to then circle back here, and add the remaining logic.

The problem is that for a workspace with around 15-20 binary targets, multiple configurations, and a reasonable expectation based on dap-mode's behaviour that it is possible to accommodate not having to go 15 layers of abstraction in, particularly given that sometimes the debug target needs to be rebuilt, and rust analyzer ensures that the build is run only when necessary... yes, you are right, we can work around it, but the user experience is not great, and it is not too much code, given that code lens support is being added to eglot.

it's fine if the answer is "I can't do it", or "I'd like to have it, but am not gonna do it myself". But I think you replied to a different issue than the one I posted.

First off, I am unfamiliar with projection-multi-dape so can't help you there.

I didn't expect otherwise. I brought it into scope, because it would dovetail into the solution.

Writing an dape integration with launch.json would be quite trivial, but it's not something I intend to do.

I would like to specifically correct you on this one. Writing the configuration is neither trivial, nor acceptable for some repositories. It depends on the path to the executable, which can result in silent errors and therefore any launch.json is potentially going to be rejected. It is also not unreasonable to not need launch.json of any kind, because DAP implementations on all major editors, including dap-mode in Emacs, obtain that information via the LSP.

dapes default configurations for rust are a bit lacking,

They require a considerable amount of nonstandard work, which should ideally be automated.

the default :program function for codelldb-rust and lldb-dap could be improved

I agree. Specifically, they should not depend on the executable being provided by the user, and instead allow for automatic configuration. This coupled with the code lenses would give you

Currently there are no specialized unit test configurations for any language package with dape

For free, because the way specific unit tests are run, is by obtaining the test id via LSP and providing the debug configuration to the DAP. This is also going to be helpful for CMake projects as well as other non-standard build systems, because the clangd and ccls LSP will have support for them in some way shape or form.

But debugging an rust compiled binary with those configurations is as simple as:

M-x dape

I'm afraid that the falseness of this statement is exactly what prompted me to create this issue. It is a good aspiration with a significant shortfall in projects in which a dap is significantly better than running gdb on the command line.

As such I would suggest that you reopen this as an issue, so I can reference it in a PR to eglot.

[svaante]

You are very much welcome to open an PR with the improvements you want just remember that you need to have done your FSF assignment and that it should fit with dapes design goals (minimal, language agnostic avoiding any specialized constructs, ergonomic config in minibuffer editing).

Or create your own package which interfaces with dape or dap-mode, elisp is a fine language.

I moved it do an discussion, if you want you can open an issue again but please be more precise as to what you are suggesting.

[divyaranjan1905]

I agree with @appetrosyan with regards to moving this to discussions, effectively disabling what is a genuine issue from being further referenced and worked upon. It's fair to expect the changes to align according to the goals you mentioned but one could've done that without closing the issue.

As someone who has been considering this package for rust development, this would only help in being more useful.