Stream: t-compiler/wg-rls-2.0

Topic: how to debug rust-analyzer's interaction with VS Code


pnkfelix (Mar 07 2019 at 13:18, on Zulip):

I'm trying to work out problems with my installation of the VS Code extension; I'm seeing essentially a bunch of "unknown file: /Users/fklock/Dev/Rust/play/src/main.rs" (see also rust-analyzer#717)

pnkfelix (Mar 07 2019 at 13:19, on Zulip):

but my most immediate question is: what is the best way to try to debug this? The two routes I can imagine are:

matklad (Mar 07 2019 at 13:19, on Zulip):

have you updated recently?

pnkfelix (Mar 07 2019 at 13:19, on Zulip):

Either 1. Try to emulate whatever request that Code is sending to ra_lsp_server, and use that locally

matklad (Mar 07 2019 at 13:19, on Zulip):

https://github.com/rust-analyzer/rust-analyzer/pull/940 should give you feedback for when stuff was loaded succesfully.

pnkfelix (Mar 07 2019 at 13:19, on Zulip):

have you updated recently?

I believe I'm using currently nightly

matklad (Mar 07 2019 at 13:20, on Zulip):

I mean, updating rust-analyzer itself. git pull & cargo jinstall-lsp

matklad (Mar 07 2019 at 13:20, on Zulip):

(j for jemalloc)

pnkfelix (Mar 07 2019 at 13:20, on Zulip):

Either 1. Try to emulate whatever request that Code is sending to ra_lsp_server, and use that locally

Or 2. Figure out how to get more debug info from the Code output terminal; e.g. figure out how to make it set RUST_LOG etc

pnkfelix (Mar 07 2019 at 13:20, on Zulip):

by "nightly" I meant

pnkfelix (Mar 07 2019 at 13:21, on Zulip):

a locally built rust-analyzer

vipentti (Mar 07 2019 at 13:21, on Zulip):

https://github.com/rust-analyzer/rust-analyzer/blob/master/DEBUGGING.md can this be used ?

pnkfelix (Mar 07 2019 at 13:21, on Zulip):

let me try to double-check whether that belief is true

matklad (Mar 07 2019 at 13:21, on Zulip):

For debugging, I just to

$ env RUST_LOG=gen_lsp_server=trace code .
pnkfelix (Mar 07 2019 at 13:21, on Zulip):

Hmm okay

pnkfelix (Mar 07 2019 at 13:21, on Zulip):

(I'm on Mac OS X so I don't always invoke things from command line)

pnkfelix (Mar 07 2019 at 13:22, on Zulip):

but I think I can get the same effect

pnkfelix (Mar 07 2019 at 13:22, on Zulip):

why "gen_lsp_server" and not "ra_lsp_server" ?

matklad (Mar 07 2019 at 13:22, on Zulip):

I belive we can set debug level here: https://github.com/rust-analyzer/rust-analyzer/blob/5232099977d07492c1b6d5e6163c70d4f6eb07df/editors/code/src/server.ts#L15-L18

matklad (Mar 07 2019 at 13:23, on Zulip):

gen_lsp_server is the "generic" lsp library, so it's the thing which actually sends and reads JSON

matklad (Mar 07 2019 at 13:23, on Zulip):

tracing it gives you the most complete picture, though its a lot of data

pnkfelix (Mar 07 2019 at 13:23, on Zulip):

ah okay. So doing RUST_LOG=gen_lsp_server would let me see the actual JSON that is sent on the "pipe"

matklad (Mar 07 2019 at 13:24, on Zulip):

I belive @DJMcNab implemented some cool tracing of requests on the client side as well: https://github.com/rust-analyzer/rust-analyzer/pull/302

matklad (Mar 07 2019 at 13:24, on Zulip):

though I've never had a chance to try that infra

vipentti (Mar 07 2019 at 13:26, on Zulip):

Yeah , you can set "rust-analyzer.trace.server": "verbose" in your settings.json to get tracing from the client

pnkfelix (Mar 07 2019 at 13:27, on Zulip):

Yeah , you can set "rust-analyzer.trace.server": "verbose" in your settings.json to get tracing from the client

oh okay well I actually did do that. But it didn't quite tell me enough for me to immediately figure out how to replicate the same input stream manually when interacting with a manually invoked ra_lsp_server

pnkfelix (Mar 07 2019 at 13:27, on Zulip):

or at least, I didn't know how to take the trace output and feed it into the running ra_lsp_server; it errors out after the first input I provided saying it expected an initialization

pnkfelix (Mar 07 2019 at 13:27, on Zulip):

(and that's about when I decided to ask in here rather than dissect further)

pnkfelix (Mar 07 2019 at 13:28, on Zulip):

https://github.com/rust-analyzer/rust-analyzer/blob/master/DEBUGGING.md can this be used ?

I hadn't actually looked at this yet, let me look now

matklad (Mar 07 2019 at 13:29, on Zulip):

Heh, I personally never try to manually feed rust-analyzer with data. Rather, I use logging/printf + running the real VS Code instance.

matklad (Mar 07 2019 at 13:29, on Zulip):

basically, if you press F5, you'll get a new vscode instance with isolated rust-analyzer

matklad (Mar 07 2019 at 13:29, on Zulip):

build freshly from source

matklad (Mar 07 2019 at 13:30, on Zulip):

If you do want to feed it "manually", the best way is probably to write a "heavy_test" in "heavy_tests/main.rs", which has some infra for communicating with ra set up

pnkfelix (Mar 07 2019 at 13:31, on Zulip):

okay. I'm not committed to either strategy (of trying to isolate ra_lsp_server vs working with the integrated setup)

vipentti (Mar 07 2019 at 13:31, on Zulip):

I think you can perform the requests manually if you run the initialization from https://github.com/rust-analyzer/rust-analyzer/blob/5232099977d07492c1b6d5e6163c70d4f6eb07df/crates/gen_lsp_server/src/lib.rs#L86-L105

pnkfelix (Mar 07 2019 at 13:31, on Zulip):

though some of the docs in DEBUGGING.md is definitely linux-centric. :smiley: :apple:

matklad (Mar 07 2019 at 13:33, on Zulip):

:-)

That's for debugger as in lldb. If you don't need that, F5 (Launch the Debug Extension, this will build the extension and the lsp server.) should "Just Work".

pnkfelix (Mar 07 2019 at 13:34, on Zulip):

okay I'll try F5

matklad (Mar 07 2019 at 13:34, on Zulip):

That said, I have "overhaul developer docs" on my todo list: we have contributing.md, architecture.md, guide.md, debugging.md, and this is just not great :(

pnkfelix (Mar 07 2019 at 13:59, on Zulip):

hmm. Now I'm not even sure if I was running the ra_lsp_server that I thought I was; I hasn't overrode that setting in my settings.json for VS Code

pnkfelix (Mar 07 2019 at 13:59, on Zulip):

is there a way to tell the ra_lsp to quit and restart itself from VS Code? Or do I need to quit VS Code and restart it (or disable the extension and reenable it?)

pnkfelix (Mar 07 2019 at 14:00, on Zulip):

/me is a VS Code newbie

matklad (Mar 07 2019 at 14:00, on Zulip):

I think you need to restart VS Code

matklad (Mar 07 2019 at 14:00, on Zulip):

/me was VS Code newbie in september

matklad (Mar 07 2019 at 14:07, on Zulip):

So, coming back to the original issue of "unknown file". My first hypothesis would be that this file just don't reside under any root, known to rust-analyzer, so I would try to add a println to the place where we initialize workspace.

vipentti (Mar 07 2019 at 14:08, on Zulip):

I think you can also run "Reload Window" in vscode to get it to restart lsp

matklad (Mar 07 2019 at 14:08, on Zulip):

If we don't have the root of the workspace as root that meanas that VS Code/rust-analyzer integration layer contains a bug

pnkfelix (Mar 07 2019 at 14:09, on Zulip):

how/where does rust-analyzer decide what/where is the sysroot? When I run it from the command line, I'm getting messages about rust-src missing and asking me to install that via rustup, but I've already done that.

matklad (Mar 07 2019 at 14:09, on Zulip):

If we do have the root, but don't see the file, that either means a bug in VFS, or some timing issues/misconceptions (i.e, VS Code asks as about file before we've scanned it, and without sending didOpenDOcument event)

matklad (Mar 07 2019 at 14:09, on Zulip):

it runts rustc --print sysroot and looks for src dir there

pnkfelix (Mar 07 2019 at 14:09, on Zulip):

ah!

matklad (Mar 07 2019 at 14:09, on Zulip):

perhaps ra uses different toolchain than the one you've added roots to?

pnkfelix (Mar 07 2019 at 14:10, on Zulip):

yeah, I have some wonkiness in my setup that can cause all kinds of problems there I bet

vipentti (Mar 07 2019 at 14:10, on Zulip):

Hmm, do you need RUST_SRC_PATH set?

vipentti (Mar 07 2019 at 14:10, on Zulip):

Or do we figure out the rust-src automatically?

matklad (Mar 07 2019 at 14:10, on Zulip):

franktly, I don't know which toolchain is used by rust-analyzer exactly :) I guess, the one in the PATH that Vscode sees?

pnkfelix (Mar 07 2019 at 14:10, on Zulip):

(e.g. I have things set up to use homebrew by default, which does have rust installed, but I never use that; I manually source ~/.cargo/env when I want to actually hack)

matklad (Mar 07 2019 at 14:11, on Zulip):

code wide, the entry point to project discovery is here: https://github.com/rust-analyzer/rust-analyzer/blob/5232099977d07492c1b6d5e6163c70d4f6eb07df/crates/ra_project_model/src/lib.rs#L44-L48

pnkfelix (Mar 07 2019 at 14:12, on Zulip):

okay, now that I (remembered to) run source ~/.cargo/env in my terminal before running code from that terminal, rust-analyzer seems to work. Next step: figure out whether the same root problem is what is plaguing Visual Studio Code when I don't run it from the terminal.

vipentti (Mar 07 2019 at 14:13, on Zulip):

Do you have rustc in your path?

pnkfelix (Mar 07 2019 at 14:13, on Zulip):

I did and do

pnkfelix (Mar 07 2019 at 14:13, on Zulip):

but the default, from homebrew, was not the one I normally use

pnkfelix (Mar 07 2019 at 14:13, on Zulip):

its like 1.30 and doesn't have the src installed, etc

pnkfelix (Mar 07 2019 at 14:14, on Zulip):

I should just de-install it

pnkfelix (Mar 07 2019 at 14:14, on Zulip):

because i think when it gets used it just ends up causing problems/confusion for me

pnkfelix (Mar 07 2019 at 14:15, on Zulip):

(and likewise I think I was also using an out-of-date versus of rust-analyzer, because I hadn't previously told the settings.json to point at the one I had locally built.)

matklad (Mar 07 2019 at 14:19, on Zulip):

Filed https://github.com/rust-analyzer/rust-analyzer/issues/945 to help with "unexpected version of rustc is picked up".

pnkfelix (Mar 07 2019 at 14:19, on Zulip):

ah that is an excellent point

pnkfelix (Mar 07 2019 at 14:19, on Zulip):

though... if there are multiple workspaces, can't they have distinct overrides?

pnkfelix (Mar 07 2019 at 14:20, on Zulip):

I may not be using the word "workspace" correctly there

pnkfelix (Mar 07 2019 at 14:20, on Zulip):

VS Code has a single workspace. But you can add multiple directories to it, and they can each represent distinct crates with distinct overrides

pnkfelix (Mar 07 2019 at 14:21, on Zulip):

that is what I am musing about

pnkfelix (Mar 07 2019 at 14:21, on Zulip):

(maybe I should be posting these thoughts elsewhere, or hold back on them until I inspect more carefully.)

matklad (Mar 07 2019 at 14:22, on Zulip):

well, yes, I think "if you work on a set of projects, they must use the same rustc version for rust-analyzer" is just the constraint we have to leave with.

pnkfelix (Mar 07 2019 at 14:23, on Zulip):

seems reasonable. Probably should detect when they differ and issue a warning

pnkfelix (Mar 07 2019 at 14:23, on Zulip):

I'll make a note on the ticket

matklad (Mar 07 2019 at 14:23, on Zulip):

Though, ideally, we should be able to state "language level" so that, for example, you can use rustc 1.92.0 for code analysis, but have a setting to check that the code is in fact compatible with rustc 1.62.0

matklad (Mar 07 2019 at 14:27, on Zulip):

In general, this "misconfiguraton" problems are a bane for IDE developers: they crop up fairly regularly, because folks use all kinds of weird set ups and you can't debug them, because everything works on your machine.

It pays off to build-in "smartness" into workspace discovery, so that users don't have to configure stuff themselves (that's why "using rustc from project dir" is better than an explicit setting for rustc). It's also helpful to issue "positive" notifications when stuff does work. In the recent versions of rust-analyzer, you get "workspace loaded" notification

pnkfelix (Mar 07 2019 at 14:28, on Zulip):

right, I have been seeing that

pnkfelix (Mar 07 2019 at 14:28, on Zulip):

but it was a little confusing, because it was coming up after the notficatin about the failure to find the rust src at the sysroot

pnkfelix (Mar 07 2019 at 14:29, on Zulip):

and so I was trying to understand whether the second notification represented some sort of recovery after the first failure

pnkfelix (Mar 07 2019 at 14:29, on Zulip):

or if they were unrelated

pnkfelix (Mar 07 2019 at 14:29, on Zulip):

(by the way, now that I've pointed my settings.json at my local build of ra_lsp_server, everything actually seems to be going very smoothly.)

pnkfelix (Mar 07 2019 at 14:31, on Zulip):

(that's why "using rustc from project dir" is better than an explicit setting for rustc)

i definitely agree inferring from project dir is the better initial default.

matklad (Mar 07 2019 at 14:37, on Zulip):

but it was a little confusing

yeah... We do try to fail gracefully if Cargo or rustc is misconfigured. Ideally, if you don't have rust installed at all, you still should have completions for local variables and such.

I am fixing the "workspace loaded" notification to say "loaded $n packages", whihc should make it clearer if stuf works or fails

matklad (Mar 07 2019 at 14:38, on Zulip):

BTW, the "unknown file" is a sort-of intentional dirty hack to surface misoconfiguration problems.

I think that to be 100% correct we should just go and read the unknown files from disk. Nothing in the LSP speck prevents that.

However, I've decided to treat that condition as a lound error for the time being, because it shows cleary if things are misconfigured. Looks like this hack worked as intended in this particular case .

matklad (Mar 08 2019 at 14:22, on Zulip):

@pnkfelix curious, which editor do you usually use? If that's Emacs, we do have a config for it in rust-analyer's repo

pnkfelix (Mar 08 2019 at 14:22, on Zulip):

yes I usually use Emacs and plan to try to investigate the .el code I saw in rust-analyzer

pnkfelix (Mar 08 2019 at 14:23, on Zulip):

but I figured I would be better off using VS Code at the outset

pnkfelix (Mar 08 2019 at 14:23, on Zulip):

since I figured that had a larger audience and thus would provide a better initial out-of-the-box experience.

Last update: Nov 12 2019 at 16:30UTC