RLS stops working after some time of use

[vorner]

Hello

I'm afraid I don't have much information about why it happens or exactly when. But here is my problem.

I start nvim and do some editing. RLS works fine for a while. But after some time, it just stops doing anything ‒ no suggestions are provided, it just sits there between processes and nothing happens. The only way to bring it back to life is to stop and start nvim again. Then, rls launches large amount of rustc compilers and starts working again.

Some things that might be relevant:

• I run cargo watch --no-restart -x test --all, which attempts to run the tests every time I save the file. That one often fails when I save the file with syntax errors (I save often, sometimes in the middle of a statement, etc). I don't know if the tests destroy some of the analyses stored somewhere when this happens.
• My code contains bunch of complex macros and generics, so it might get confused.

To be clear, I understand it is problematic doing analysis on syntactically incorrect code, but what I find annoying is the fact RLS doesn't recover after I fix the code.

Versions:

rls 0.1.0-nightly (79d659e 2017-07-26)
rustc 1.21.0-nightly (599be0d18 2017-07-26)

I understand this report is of little use as it is, because there's not much info. I'd try to debug it, but I don't really know where to start and I didn't find any docs how to get some kind of log file from it, or something. So, is there some experiment I might run to get something useful out of it?

[Dushistov]

@vorner what about put such rls into PATH env variable before actual rls:

#!/bin/sh

RUST_LOG=debug path/to/real/rls $@ > /tmp/rls.log 2>&1

?

And look what is inside /tmp/rls.log?

[nrc]

If you run Cargo outside the RLS it should put its data in a separate target dir from the RLS. The only overlap is if you run cargo clean, that will destroy all data including the RLS's.

The RLS shouldn't be bothered my source code complexity - it just uses the compiler, so at worst we should just get sub-optimal data.

It is possible that running the RLS on incorrect syntax causes problems. We try to cope, but there are a lot of edge cases and its possible we're hitting something bad.

I'm not sure how NeoVim handles logging. It might be easier to try to repro in VSCode (or try @Dushistov's log file suggestion).

You can set RUST_LOG=info or trace to get more info (we tend to use debug messages only for erros).

[vorner]

Thank you for the suggestions, I'll try the shell script thing once I get to coding again during the next week. I kind of expected something more sophisticated and this simple thing so this simple one didn't cross my mind O:-)

I'll get back soon with some data.

[cars10]

I experience the same issue. Two days ago it worked, now i cannot use go-to-definition. I use newest rustc rustc 1.21.0-nightly (126321e2e 2017-07-28) .

Edit: code completion seems to be working though

[vorner]

I didn't manage to catch it happening again yet. However, there's another important bit of information that might be relevant. I have CARGO_INCREMENTAL=1 set in my environment. Can rls be influenced by that? It seems rustc sometimes caches some slightly broken data (rust-lang/rust#43587).

[vorner]

OK, I have a log now. I think there's something relevant (some errors and then backtraces), and I hope this'll help someone with the knowledge of rls's code.

rls.log.txt

[nrc]

So the root cause here seems to be Cargo not being able to find a fingerprint it thinks it should be able to:

CargoError(Internal(Msg("failed to stat `/home/vorner/work/pakon/aggregator/target/rls/debug/.fingerprint/aggregator-e396cab72944abc7/dep-bin-pakon_aggregator-e396cab72944abc7`")), State { next_error: Some(Error { repr: Os { code: 2, message: "No such file or directory" } })

There were a lot of compile errors earlier, I think in the aggregator crate, but not 100% sure, and then the following:

INFO:cargo::ops::cargo_rustc: Renaming dep_info "/home/vorner/work/pakon/aggregator/target/rls/debug/deps/aggregator-6d6c0ee4c72d1256.d" to "/home/vorner/work/pakon/aggregator/target/rls/debug/.fingerprint/aggregator-6d6c0ee4c72d1256/dep-lib-aggregator-6d6c0ee4c72d1256"
INFO:cargo::ops::cargo_rustc::job_queue: end: aggregator v0.1.0 (file:///home/vorner/work/pakon/aggregator) => Target(lib)/Profile(check) => Host
INFO:cargo::ops::cargo_rustc::job_queue: start: aggregator v0.1.0 (file:///home/vorner/work/pakon/aggregator) => Target(bin: pakon-aggregator)/Profile(check) => Host
{"message":"extern location for aggregator does not exist: /home/vorner/work/pakon/aggregator/target/rls/debug/deps/libaggregator-6d6c0ee4c72d1256.rmeta","code":null,"level":"error","spans":[],"children":[],"rendered":null}
{"message":"extern location for aggregator does not exist: /home/vorner/work/pakon/aggregator/target/rls/debug/deps/libaggregator-6d6c0ee4c72d1256.rmeta","code":null,"level":"error","spans":[],"children":[],"rendered":null}
{"message":"can't find crate for `aggregator`","code":{"code":"E0463","explanation":"\nA plugin/crate was declared but cannot be found. Erroneous code example:\n\n```compile_fail,E0463\n#![feature(plugin)]\n#![plugin(cookie_monster)] // error: can't find crate for `cookie_monster`\nextern crate cake_is_a_lie; // error: can't find crate for `cake_is_a_lie`\n```\n\nYou need to link your code to the relevant crate in order to be able to use it\n(through Cargo or the `-L` option of rustc example). Plugins are crates as\nwell, and you link to them the same way.\n"},"level":"error","spans":[{"file_name":"src/bin/pakon-aggregator.rs","byte_start":763,"byte_end":787,"line_start":20,"line_end":20,"column_start":1,"column_end":25,"is_primary":true,"text":[{"text":"extern crate aggregator;","highlight_start":1,"highlight_end":25}],"label":"can't find crate","suggested_replacement":null,"expansion":null}],"children":[],"rendered":null}

Note that the hashes for the crate are different in these earlier logs than they are in the missing file error.

I would usually expect the RLS to cope with compile errors, but perhaps the fact that this is happening across crates is confusing?

@vorner are you working with multiple crates here? Which is the crate that you were editing and which is the crate that the RLS is watching?

[vorner]

If by multiple crates you mean a workspace, then no. It's a single crate, but it has both lib and bin. However, I was editing only the lib and I didn't touch the bin at all at the time (the bin is just a thin wrapper). I have no rls.toml, so it probably watched the lib.

Yes, when I edit, I often have a lot of compilation errors. I was refactoring at that time, so whenever I change a type or something, it causes errors across several files.

The project is here, if you want to look at the layout or if I'm unclear about anything: https://gitlab.labs.nic.cz/turris/pakon-aggregator.

[vorner]

It really seems to be somehow related to CARGO_INCREMENTAL=1 in the environment. I'm running rls through this wrapper:

#!/bin/sh

RUST_LOG=info CARGO_INCREMENTAL=0 nice -n2 rustup run nightly rls "$@" 2>"$HOME"/.rls.log

and I haven't seen it crash since (it's 2 days now). That doesn't necessarily mean anything (it didn't crash that often), but it feels the problem went away.

The other compilations and the rest of my environment still runs with CARGO_INCREMENTAL=1, just RLS is excluded from it.

[nrc]

cc #132 and @Xanewok: possibly a lib/bin issue?

[vorner]

Also, if you want to look into it, that project switched to workspace mode since the report. The 15382717abbaea169b544d6d6e9416fb4fae79b8 commit should still be before the switch.

[flukejones]

Using the wrapper above I was able to a log from a crash I'm able to consistently duplicate.
.rls.log

Initially I'd mistaken it for a Gnome-Builder crash and logged the steps here

The root cause always seems to be auto-completing matching braces on macros. Well, in this case at least.

CARGO_INCREMENTAL=0 doesn't prevent it. Neither does a cargo clean before opening the project.

Edit: a second crash with different log output
.rls.log, of note here is:

*lots like this*
INFO:cargo::ops::cargo_rustc::fingerprint: fingerprint error for serde_derive_internals v0.17.0: failed to read `/home/luke/src/projects/rs_game_framework/target/rls/debug/.fingerprint/serde_derive_internals-d3a2f395fad32cc6/lib-serde_derive_internals-d3a2f395fad32cc6`
INFO:cargo::ops::cargo_rustc::fingerprint:   cause: failed to read `/home/luke/src/projects/rs_game_framework/target/rls/debug/.fingerprint/serde_derive_internals-d3a2f395fad32cc6/lib-serde_derive_internals-d3a2f395fad32cc6`
INFO:cargo::ops::cargo_rustc::fingerprint:   cause: No such file or directory (os error 2)
*end of output is*
{"message":"could not exec the linker `cc`: No such file or directory (os error 2)","code":null,"level":"error","spans":[],
*snipped json out*
{"message":"aborting due to previous error","code":null,"level":"error","spans":[],"children":[],"rendered":null}

[nrc]

I checked out the given commit and when I run the RLS I get a warning that Cargo failed on a dependent crate due to a compile error. Since the RLS doesn't have a dep, it can't build the main crate so there is no type info etc. However, this is expected behaviour, we emit a warning and we don't crash. I think the problem before was that we used to crash in this situation.