feat: add debug code lens

[hdevalke]

Refs #3539

[SomeoneToIgnore]

Great!
I really like how both debug and run lens are placed into a single line.

Yet there's an error that happens for me when I click on the same debug lens multiple times:

Running `cargo test --package ra_ide --lib --no-run --no-run --no-run --no-run --no-run --no-run --message-format=json`...
error: The argument '--no-run' was provided more than once, but cannot be used multiple times

USAGE:
    cargo test --lib --message-format <FMT>... --no-run --package <SPEC>...

For more information try --help

as if we forget to clean some Vec with parameters.

[kjeremy]

I like this but I've never been able to get vscode-lldb to work under my windows install and have to use nativedebug instead to get msvc support. I'm not convinced that making rust-analyzer depend on vscode-lldb is the right thing to do.

[edwin0cheng]

Neat! But I agreed with @kjeremy , depends on vscode-lldb directly may not be the best option here. (I am in Windows too) I was skimming the PR and found that we actually didn't use any vscode-lldb function directly. So , I wonder what happen whether it is possible if we remove:

"extensionDependencies": [
        "vadimcn.vscode-lldb"
    ],

And let vscode itself to resolve what Debugger to use ?

[matklad]

cc @vadimcn for general awareness :)

[matklad]

r=me with nits addressed

[kjeremy]

I really think the dependency on vscode-lldb is worth a discussion before merging.

…

On Thu, Mar 12, 2020, 11:42 AM Aleksey Kladov ***@***.***> wrote: r=me with nits addressed — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3561 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABBACRFSVSRFAAHX66XNQFDRHD7FXANCNFSM4LF6QOTQ> .

[matklad]

I am def on-board with adding vs-code lldb as a dependency. Like, if you use Rust, you probably need to have a way to debug it anyway. I don't immediately see any costs here (are there some?), but I do see benefits.

[kjeremy]

@matklad right but we need to use a different debugger extension on windows.

[matklad]

Ah, that's a bummer. But code-lldb works with mingw toolchain on windows, right? i guess we can start with code-lldb and than add windows support...

[kjeremy]

Good question. I don't have mingw installed on my windows box. I was talking about msvc above.

[bjorn3]

Is there a way to only show the code lens when code-lldb is installed instead of requiring code-lldb?

[kjeremy]

Is there something bin the debugger api we could use to make it debugger agnostic?

…

On Thu, Mar 12, 2020, 2:30 PM bjorn3 ***@***.***> wrote: Is there a way to only show the code lens when code-lldb is installed instead of requiring code-lldb? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3561 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABBACRB7HTWLQZXMIJ65JBTRHES3LANCNFSM4LF6QOTQ> .

[Veetaha]

There do is a way to find out whether code-lldb is installed. As a workaround we could pass a false flag if code-lldb is not detected on the frontend.

const enableDebugTestCodeLens = vscode.extensions.getExtension("vadimcn.vscode-lldb") != null;

[vadimcn]

@kjeremy: Debugging with PDB is supposed to work (though not as well as with DWARF debug info). But I don't see any bug reports from you in my tracker, so can't comment on your troubles. :)

In general, I can concur with the reluctance to hardcode a dependency on a specific extension. After all, the bus factor of CodeLLDB is currently equal to one.

Unfortunately, it is not so easy to be debugger-agnostic, because VSCode did not standartize launch configuration schemas. There isn't a general agreement on how the executable, its arguments and environment variables should be specified.

The best thing I can propose is to allow users to specify the entire launch config with placeholders for things like executable path, test name, etc. VSCode does not provide tools to expanding placeholders out of the box, but it doesn't take too much code to do it yourself.

Another thing you might want to consider would be a configurable "cargo runner". This would allow users to start tests in CLI debuggers. CodeLLDB supports this mode as well.

[Veetaha]

I did struggle with installing vscode-lldb on Windows some time ago. And I failed to do this due to a lot of problems with finding the python interpreter and python related stuff at all. Even on my current Ubuntu os I did have a trouble of findning libpython

{
    "lldb.libpython": "/usr/lib/x86_64-linux-gnu/libpython3.6m.so",
}

Since I am not into python stuff at all, I didn't try to elaborate on this much.
@kjeremy , do you have a similar problem?

[hdevalke]

@SomeoneToIgnore

Yet there's an error that happens for me when I click on the same debug lens multiple times

Solved by moving the logic to the LSP.

[hdevalke]

@Veetaha

As a workaround we could pass a false flag if code-lldb is not detected on the frontend.

Any idea how this could be passed on from the vscode extension to the function fn handle_code_lens?
I see WorldSnapshot has feature_flags and options, but I don't know how to set this based on vscode.extensions.getExtension("vadimcn.vscode-lldb") != null;

[Veetaha]

@hdevalke
On the frontend side you might want to add an appropriate getter here:
https://github.com/rust-analyzer/rust-analyzer/blob/fab40db8bdfdac5cde5789f74d1ec28e60a8bb7e/editors/code/src/config.ts#L26
then passing the flag to initializationOptions:
https://github.com/rust-analyzer/rust-analyzer/blob/fab40db8bdfdac5cde5789f74d1ec28e60a8bb7e/editors/code/src/client.ts#L29

On the server side ServerConfig reflects initializationOptions:
https://github.com/rust-analyzer/rust-analyzer/blob/fab40db8bdfdac5cde5789f74d1ec28e60a8bb7e/crates/rust-analyzer/src/config.rs#L18

And then it gets mapped to Options that are then passed in WorldSnapshot.options property:
(I am not sure we should use FeatureFlags for this purpose, though @matklad should elaborate on this)
https://github.com/rust-analyzer/rust-analyzer/blob/2f9f409538553fc709bbcad1a5c76968f36e5968/crates/rust-analyzer/src/main_loop.rs#L170-L192

[hdevalke]

@Veetaha thanks for the tips. I'll have a look.

[hdevalke]

@Veetaha auto detection works, but the documentation probably has to be updated to inform users how to debug with rust-analyzer in combination with vscode-lldb.

[Veetaha]

Regrading the docs we might add some words about the debug code lens in features.md somewhere in VS Code section I guess https://github.com/rust-analyzer/rust-analyzer/blob/master/docs/user/features.md

[Veetaha]

Maybe it is also worth to mention vscode-lldb as an optional dependency in the installation guide

[matklad]

bors r+

[bors]

Build succeeded

• Rust (ubuntu-latest)
• Rust (macos-latest)
• Rust (windows-latest)
• TypeScript

[doivosevic]

Are there any docs where we can see how this is supposed to work?
I have a very simple test code and I only have the "Run test" option, and no "Debug". How is this supposed to work?

I'm on Windows 10 with rust-analyzer 0.2.344

[hdevalke]

Having CodeLLDB or C++ tools Windows debugger installed in vscode should be enough.