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?
Did you compile with debug info?
I just ran
cargo build. Doesn't it compile with debug symbols enabled?
Oh, thanks! By the way, the project already takes 13GB, I wonder how much it would take with debug symbols)
If you use
debug = 1, instead of the default
debug = 2 , it will only add lineinfo, but not info required to show locals, etc
You can also use
[profile.dev.package.abc] to only change settings for crate
Can you please hint me if there is a cli option for
cargo for debug level?
No, you can use
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)
I’d say the easiest would be to teach rust-analyzer to generate appropriate
debugger invocation, and then just using this feature :)
Debug test right near
Run test button would be super helpful )
Hmm, I found a good extension dedicated just for that https://github.com/hdevalke/rust-test-lens
@matklad To my mind we should integrate this
Debug test functionality directly into
rust-analyzer. What do you think?
We absolutely should
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
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
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
The extension I provided the link to does this purely without the LSP. We could roughly copy-paste that code)
I personally am very well acquainted with TypeScript, so it would be a jiffy
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)
So I think we should rather extend the current code for "runnables"
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.
The relevant bits are
Thanks! And just FYI, I found the link to the extension from this issue:
@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
@pachi, thanks for the link, though I already mentioned it higher in the discussion)
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.
@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.
That is so cool and useful, thanks for sharing
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?
They probably only work with build-in pretty-printers
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
This is the problem of watching expressions at all, they somehow use python syntax but not rust
For example, when I try to evaluate a + b, both i32, it says
int(a) + int(b) works. Its something weird like
b are python strings