Stream: t-compiler/wg-rls-2.0

Topic: vscode_debug


std::Veetaha (Jan 26 2020 at 15:00, on Zulip):

I am debugging ra_lsp_server with vscode. I've caught a panic, but cannot step into source code all functions in the callstack are shown only in assembly language. Does someone know how to switch to source code here?
pasted image

bjorn3 (Jan 26 2020 at 15:00, on Zulip):

Did you compile with debug info?

std::Veetaha (Jan 26 2020 at 15:01, on Zulip):

I just ran cargo build. Doesn't it compile with debug symbols enabled?

Jonas Schievink (Jan 26 2020 at 15:01, on Zulip):

nope: https://github.com/rust-analyzer/rust-analyzer/blob/master/Cargo.toml#L7

std::Veetaha (Jan 26 2020 at 15:02, on Zulip):

Oh, thanks! By the way, the project already takes 13GB, I wonder how much it would take with debug symbols)

bjorn3 (Jan 26 2020 at 15:04, on Zulip):

If you use debug = 1, instead of the default debug = 2 , it will only add lineinfo, but not info required to show locals, etc

bjorn3 (Jan 26 2020 at 15:05, on Zulip):

You can also use [profile.dev.package.abc] to only change settings for crate abc

std::Veetaha (Jan 26 2020 at 15:05, on Zulip):

Can you please hint me if there is a cli option for cargo for debug level?

bjorn3 (Jan 26 2020 at 15:06, on Zulip):

No, you can use RUSTFLAGS="-Cdebuginfo=1" or RUSTFLAGS="-Cdebuginfo=2" though

std::Veetaha (Jan 26 2020 at 15:07, on Zulip):

Okay, thanks!

std::Veetaha (Jan 26 2020 at 17:01, on Zulip):

Guys, how do you debug unit tests in vscode? I see that test binaries a very hard to take apart from other binaries. The only way I see now is running cargo test --no-run --message-format=json > artifacts.json, then manually looking up the test binary name and setting it in launch.json (I think I'd write a script for this)

matklad (Jan 26 2020 at 17:08, on Zulip):

I’d say the easiest would be to teach rust-analyzer to generate appropriate
debugger invocation, and then just using this feature :)

std::Veetaha (Jan 26 2020 at 17:10, on Zulip):

Yeah, Debug test right near Run test button would be super helpful )

std::Veetaha (Jan 26 2020 at 17:17, on Zulip):

Hmm, I found a good extension dedicated just for that https://github.com/hdevalke/rust-test-lens

std::Veetaha (Jan 26 2020 at 20:02, on Zulip):

@matklad To my mind we should integrate this Debug test functionality directly into rust-analyzer. What do you think?

matklad (Jan 27 2020 at 09:56, on Zulip):

We absolutely should

matklad (Jan 27 2020 at 09:57, on Zulip):

The problem is that this is not expressible in the LSP protocol (and even in the VS Code API), so that would need some custom code to handle

matklad (Jan 27 2020 at 09:59, on Zulip):

Moreover, I would love to see this implemented in a very generic manner, like "the server specifies the command line to invoke something, the debugger than injects its stuff into the command line", but that doesn't work out naturally, as you don't know the name of the output file with tests beforehand

matklad (Jan 27 2020 at 10:00, on Zulip):

So, we need this whole dance with "execute once with --message-format=json, then build the command line invocation", and it's not clear what's the best way to implement this. Like, which parts are in the client, which parts are in the server

std::Veetaha (Jan 27 2020 at 10:00, on Zulip):

The extension I provided the link to does this purely without the LSP. We could roughly copy-paste that code)

std::Veetaha (Jan 27 2020 at 10:01, on Zulip):

I personally am very well acquainted with TypeScript, so it would be a jiffy

matklad (Jan 27 2020 at 10:02, on Zulip):

I think we should at least keep test discovery on the server side (because that would be able to deal with proc macros one day)

matklad (Jan 27 2020 at 10:02, on Zulip):

So I think we should rather extend the current code for "runnables"

std::Veetaha (Jan 27 2020 at 10:05, on Zulip):

Okay, I am not yet into higher-level stuff of our LSP, but nevertheless, this needs more thorough investigation. I'll create an issue for that, I guess.

matklad (Jan 27 2020 at 10:07, on Zulip):

The relevant bits are

std::Veetaha (Jan 27 2020 at 10:10, on Zulip):

Thanks! And just FYI, I found the link to the extension from this issue:
https://github.com/rust-analyzer/rust-analyzer/issues/2593

pachi (Jan 27 2020 at 12:10, on Zulip):

@std::Veetaha @matklad Maybe this interests you. The "Rust test lens" extension for VSCode is very nice for debugging (or running) just a test from the code, which is, AFAICT, what you're looking for. The extension repo is at https://github.com/hdevalke/rust-test-lens

std::Veetaha (Jan 27 2020 at 14:16, on Zulip):

@pachi, thanks for the link, though I already mentioned it higher in the discussion)

pachi (Jan 27 2020 at 14:27, on Zulip):

Oh, sorry for the noise, then. I read your message yesterday while on the phone and tried to send the information today just in case.

std::Veetaha (Feb 01 2020 at 10:26, on Zulip):

@matklad , I've read about your debugging workflow. It seems that you are unaware of VSCode logpoints, these are just like debugger breakpoints, but the debugger doesn't stop at them, but instead logs an expression at that point. It means you don't have to literally put dbg!() expressions into the code and recompile it, but just put a logpoint there and rerun the already compiled binary.
logpoints.gif

Emil Lauridsen (Feb 01 2020 at 10:56, on Zulip):

That is so cool and useful, thanks for sharing

matklad (Feb 01 2020 at 13:45, on Zulip):

Indeed I am not aware of that, that's cool, thanks for sharing! Do they work with Debug impls, or only with build-in pretty-printers?

bjorn3 (Feb 01 2020 at 13:46, on Zulip):

They probably only work with build-in pretty-printers

std::Veetaha (Feb 01 2020 at 14:31, on Zulip):

I personally don't have idea, it uses some python scripting underneath, so that to get the length of Vec<T> you have to type len(vec) instead of vec.len()

std::Veetaha (Feb 01 2020 at 14:32, on Zulip):

This is the problem of watching expressions at all, they somehow use python syntax but not rust

std::Veetaha (Feb 01 2020 at 14:35, on Zulip):

For example, when I try to evaluate a + b, both i32, it says <not available>

std::Veetaha (Feb 01 2020 at 14:35, on Zulip):

But int(a) + int(b) works. Its something weird like a and b are python strings
pasted image

std::Veetaha (Feb 26 2020 at 20:54, on Zulip):

Does one know a legal way to debug rust-analyzer from the entrypoint (i.e. not to attach the debugger in the middle of running the main_loop, but from the beginning)?

Laurențiu Nicola (Feb 26 2020 at 21:06, on Zulip):

Put a thread::sleep at the beginning of main? :sweat_smile:

std::Veetaha (Feb 26 2020 at 21:10, on Zulip):

I found a better solution, though still illegal:
image.png

Laurențiu Nicola (Feb 26 2020 at 21:12, on Zulip):

sleep might be better because it doesn't require you to change a variable value or the next instruction using the debugger

matklad (Feb 26 2020 at 21:12, on Zulip):

https://doc.rust-lang.org/std/intrinsics/fn.breakpoint.html

Laurențiu Nicola (Feb 26 2020 at 21:13, on Zulip):

5 seconds or so should be enough to attach a debugger

std::Veetaha (Apr 02 2020 at 20:11, on Zulip):

Hey guys, does anyone have a problem with taking screenshots of on-hover hints in vscode (Ubuntu)? I remember some time ago this worked well. But something changed and I can no longer make partial screenshots of hover info because it disappears once I press Shift+PrtSc in vscode and this drives me mad...
screen.gif

Jeremy Kolb (Apr 02 2020 at 20:59, on Zulip):

it works in windows

Jeremy Kolb (Apr 02 2020 at 20:59, on Zulip):

i've seen a lot of weirdness with vscode in my ubuntu vm though.

Jeremy Kolb (Apr 02 2020 at 20:59, on Zulip):

white menus etc. there are definitely electron issues

Laurențiu Nicola (Apr 03 2020 at 08:11, on Zulip):

It works for me on Gnome Wayland / Arch Linux:

image.png

Last update: Jun 07 2020 at 10:35UTC