-
Notifications
You must be signed in to change notification settings - Fork 255
Failing to build the lib portion of a project crashes the RLS on the bin portion #443
Comments
Looks like Cargo can't read a fingerprint file from disk. You could try a |
@nrc I'll try Unfortunately, I can't try another client easily as this is under WSL and VSCode would execute out of the WSL environment. |
This is with RUST_BACKTRACE=full:
It seems to be fully reproducible based off the completions that my navigation in the code are triggering. |
OK, it seems that I have the strace output, if it's worth anything to you, from the failed RLS runs (attached). |
Hello. I'm getting the same or very similar problem now, since I updated this morning. I'm not sure this is exactly the same problem, but it seems to act in the same way. Few things of note:
I have a log output of rls itself (I can re-run it with something more verbose than info): The error is similar to this one too, but it happens with And yes, this is the same project as in #440. Is this the same problem? Or, should I open a different issue? Can I help debugging it somehow? While I know close to nothing about how rls works internally, I might try some debugging (but some hints or suggestions what to check and see would really help). Thank you |
@vorner The error is due to Cargo assuming that a nonexistent fingerprint for an artifact is a fatal error for its build tasks; when a library project fails to build, its result artifact naturally won't exist, and when the bin references that nonexistent artifact Cargo then panics. Which it should, I can't think of what else would be a suitable response. The problem is that RLS quits or crashes because of this. It needs to note the failure but continue operating as if that were another error causing the build to fail. I'll keep looking into it. |
Now that I think about it, maybe when running |
@jTitor I'm not sure about that. First, I didn't open a file in the bin, but in the lib. So why did RLS even touch that bin part? The other thing is, the logs in #440 also contain errors with missing fingerprints. However, the code compiles correctly and RLS does not crash (it just doesn't provide all the functionality). So I don't know if that deduction goes a bit too far. Anyway, as I said, I have no real idea what happens inside RLS, just that the fingerprint error leads to the crash only sometimes. |
cc #132 |
This is fixed now. |
Using neovim LanguageClient, running the latest nightly toolchain/rls/src/etc I get the following (every time):
I will attempt to get the full backtrace. Any suggestions?
The text was updated successfully, but these errors were encountered: