I'm trying to dig into https://github.com/rust-analyzer/rust-analyzer/issues/2202 a little bit
but adding println!()
calls in the ra_lsp_server don't show up anywhere as far as I can see
neither do log::error!()
messages
any hint on how I could debug this thing?
even when running env RUST_LOG=gen_lsp_server=trace
, I don't see anything show up in the "Rust Analyzer Language Server Trace" tab
Did you check the box in the vscode settings?
Sorry.... not a box. It's a trace option
I did now and there is some output
but not anything I log or print from inside the server, as far as I can tell
It might be ra_lsp_server
instead of gen_lsp_server
now
sounds sensible, but I don't see it making a difference
ahhh, found it
?
there was a different tab called "Rust Analyzer Language Server"
Acutally I wanted to show you the RA_LOG_DIR
, but I should have said that, sorry
Glad you got it working though
Yeah, there are two tabs, one for client-side tracing of requests, on for server-side logging
note that we use stdout to communicate with the client, so println breaks things at the root
eprintln should be fine
@matklad the WorldState
seems to be aware of all my workspaces just fine
but somehow compilation feedback only shows up for the first one in the list (which happens to also be the rootPath
, although it seems that ends up not being used if multiple workspaces are defined)
any thoughts on where I should look next?
note that we use stdout to communicate with the client, so println breaks things at the root
FWIW: This cost me about an hour to find out why nothing worked anymore after I tried to debug my RA changes. I had no idea it could have been related to the debug statements I added. Maybe some notification could emitted to prevent that. E.g. if VsCode detects malformed LSP requests, it shows up popup/notification or emits something in the extension log that says "Do not use println!
for debugging. If you don't and still get this error, file a bug report".
@Dirkjan Ochtman interesting. The next thing to look at would probably be FileLoaderDelegate::relevant_crates
-- this function should return a list of crates (compilation units), that can contain the given file. If that also returns a non-empty result, then the best thing to do would probably be to try to create a minimal reproduction, as I don't think there are more places where we can bisect the logic.
@Matthias247 ah, we actually even lock stdout in the server, so println
s just deadlock. Let's just override println in the server lib...
@Matthias247 https://github.com/rust-analyzer/rust-analyzer/pull/2349 should help in the future!
Matthias247 https://github.com/rust-analyzer/rust-analyzer/pull/2349 should help in the future!
Does that help if you use println!
in any of the other rust-analyzer crates? Like I tried in ra-project-model
?
@Matthias247 nope, it doesn't :(