Open teymour-aldridge opened 1 week ago
Same issue here. Here's what the LSP log looks like when running Zed with RUST_BACKTRACE=full
Environment: Zed: 0.150.4 Kernel: 6.10.7-arch1-1 OS: ArcoLinux rolling
I've filed this with rust analyzer: https://github.com/rust-lang/rust-analyzer/issues/18055.
If you are experiencing this on smaller projects than Zed itself, then please add them to the issue to help the rust analyzer team diagnose.
I've also been running into this.
stderr: thread 'RUST_BACKTRACE=full
for a verbose backtrace.
stderr: thread 'LspServer' panicked at /Users/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/lsp-server-0.7.6/src/stdio.rs:59:17:
stderr: BoxRUST_BACKTRACE=full
for a verbose backtrace.
stderr: thread 'main' panicked at /Users/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/jod-thread-0.1.2/src/lib.rs:33:22:
stderr: called Result::unwrap()
on an Err
value: Any { .. }
stderr: stack backtrace:
stderr: 0: _rust_begin_unwind
stderr: 1: core::panicking::panic_fmt
stderr: 2: core::result::unwrap_failed
stderr: 3: stdx::thread::JoinHandleRUST_BACKTRACE=full
for a verbose backtrace.
As a temporary workaround you can downgrade to the previous version of rust analyzer by:
~/Library/Application Support/Zed/languages/rust-analyzer/rust-analyzer-2024-09-02
This will mean Zed thinks it is up-to-date even though it isn't.
Note, that if you download through a browser you will need to clear the security bits or MacOS will refuse to run the binary. To do so open that folder in finder with cd ~/Library/Application Support/Zed/languages/rust-analyzer; open .
; then right click on rust-analyzer-2024-09-02
and click Open. Click Open again when prompted to clear the security problems.
As stated in the r-a issue, these logs don't reveal anything too interesting, except for one thing I'm now curious about (after seeing the logs). Does this happen when zed tries to shut down the server? (asking due to the spammy Generic lsp request to rust-analyzer failed: server shut down
)
Edit: Ah I see I misinterpreted the logs. The server has shut down due to the panics and zed just becomes chatty with that then I suppose.
We're not explicitly shutting down the server in this case - though I'm not sure what triggers it to crash. I'll see if I can get more detail next week with your panic code cleanup
Can zed detect this condition and automatically restart the language server? That is how I'm working around this in daily use.
That or a similar mitigation might improve the user experience in the face of arbitrary unreliabilities in the underlying language servers.
Fwiw, VSCode restarts language servers up to 5 times before it fully keeps them shutdown in a session (and iirc the LSP even recommends that clients should behave somewhat like that).
It would be nice if anyone running into this with the latest rust-analyzer (from this week and onwards) could post their backtrace as we changed some things which should make it clearer what could be causing this and/or if there is a reproduction, describe how to reproduce it then i can look into it myself.
Happy to help, but can you explain where to find the backtrace, and if there are any settings or variables I need to set to enable the logs? rust-analyzer is crashing every few hours for me, but my Zed log does not show a backtrace.
You can find them with cmd-shift-p debug: open language server logs
and then selecting the right language server from the drop down.
Okay no need to anymore, figured it out https://github.com/rust-lang/rust-analyzer/issues/18055#issuecomment-2345334003 its zed incorrectly sending textDocument/didSave
and r-a not handling it well when that happens
Getting a lot of problems with rust-analyzer on zed, both preview and stable. Seems like after a while it crashes no matter what. Then no inlay hints not auto completion.
OS: macOS 13.5.2 Memory: 16 GiB Architecture: aarch64
2024-09-13T18:35:56.615032+01:00 [WARN] Generic lsp request to rust-analyzer failed: server shut down 2024-09-13T18:35:56.615174+01:00 [ERROR] Broken pipe (os error 32) 2024-09-13T18:35:56.615301+01:00 [ERROR] server shut down 2024-09-13T18:35:56.748944+01:00 [WARN] Generic lsp request to rust-analyzer failed: server shut down 2024-09-13T18:35:56.749268+01:00 [ERROR] server shut down 2024-09-13T18:35:56.932527+01:00 [WARN] Generic lsp request to rust-analyzer failed: server shut down 2024-09-13T18:35:56.93289+01:00 [ERROR] server shut down 2024-09-13T18:35:57.706124+01:00 [WARN] Generic lsp request to rust-analyzer failed: server shut down 2024-09-13T18:35:57.706416+01:00 [ERROR] inlay hint update task for range failed: Error { context: "inlay hint fetch task", source: Error { context: "inlay hints LSP request", source: "server shut down", }, } 2024-09-13T18:35:58.121628+01:00 [WARN] Generic lsp request to rust-analyzer failed: server shut down 2024-09-13T18:35:58.267124+01:00 [WARN] Generic lsp request to rust-analyzer failed: server shut down 2024-09-13T18:35:58.267507+01:00 [ERROR] inlay hint update task for range failed: Error { context: "inlay hint fetch task", source: Error { context: "inlay hints LSP request", source: "server shut down", }, }
On Linux, the following workaround can be used:
$ rustup update
$ rustup component add rust-analyzer
$ rust-analyzer --version
rust-analyzer 1.81.0 (eeb90cda 2024-09-04)
$ rm $HOME/.local/share/zed/languages/rust-analyzer/rust-analyzer-*
Then, change the Zed configuration to look up rust-analyzer via $PATH
:
{
"lsp": {
"rust-analyzer": {
"binary": { "path_lookup": true }
}
}
}
The rustup component does not have the fix on the rust-analyzer side in it. That won't be a working workaround
On Linux, the following workaround can be used:
$ rustup update $ rustup component add rust-analyzer $ rust-analyzer --version rust-analyzer 1.81.0 (eeb90cda 2024-09-04) $ rm $HOME/.local/share/zed/languages/rust-analyzer/rust-analyzer-*
Then, change the Zed configuration to look up rust-analyzer via
$PATH
:{ "lsp": { "rust-analyzer": { "binary": { "path_lookup": true } } } }
This actually works for me. I'm using macOS. Thanks. At least got a workaround.
I think this bug is making zed almost unusable for rust project for now.
On Linux, the following workaround can be used:
$ rustup update $ rustup component add rust-analyzer $ rust-analyzer --version rust-analyzer 1.81.0 (eeb90cda 2024-09-04) $ rm $HOME/.local/share/zed/languages/rust-analyzer/rust-analyzer-*
Then, change the Zed configuration to look up rust-analyzer via
$PATH
:{ "lsp": { "rust-analyzer": { "binary": { "path_lookup": true } } } }
This actually works for me. I'm using macOS. Thanks. At least got a workaround.
I think this bug is making zed almost unusable for rust project for now.
Thank you for that. I tried it, it still crashes. It seems to happen quicker when I swap LSP. Currently editing a codebase with both Rust and TSX, and it seems to crash quicker when I start editing tsx files.... Frustrating....
Also getting a strange output on the rust-analyzer now.
➜ Zed rust-analyzer --version rust-analyzer 0.0.0 (08c7bbc2d 2024-09-06) ➜ Zed
Check for existing issues
Describe the bug / provide steps to reproduce it
After a few minutes of use rust-analyzer crashes.
Environment
Zed: v0.151.1 (Zed) OS: macOS 13.5.2 Memory: 16 GiB Architecture: aarch64
If applicable, add mockups / screenshots to help explain present your vision of the feature
Error messages from rust-analyzer (server trace and RSP messages are both empty)
If applicable, attach your Zed.log file to this issue.
Zed.log