rust-analyzer: proc macro not expanded: failed to write request (os error 232) on Windows

rust-analyzer version: rust-analyzer version: 0.3.1791-standalone (9db515503 2024-01-01)

rustc version: rustc 1.77.0-nightly (595bc6f00 2024-01-05)

relevant settings: none

proc macro Serialize not expanded: failed to write request: 管道正在被关闭。 (os error 232) rust-analyzer unresolved-proc-macro

OS: Windows11

Reproduce:

cargo new test-ra
cd test-ra
cargo add serde -F derive
// src/main.rs
use serde::Serialize;
#[derive(Serialize)]
pub struct A {}
fn main() {}

Found a related but closed issue: https://github.com/rust-lang/rust-analyzer/issues/14991

About this issue

  • Original URL
  • State: closed
  • Created 6 months ago
  • Comments: 25 (10 by maintainers)

Most upvoted comments

@benfaerber FYI if you use LSP plugins in neovim that install RA (say mason), it’s likely not to use RA installed from rustup, which also cause outdated RA with newer toolchain.

As was said you’ll need to update your rust-analyzer to a newer version./

Yes, to add context. This issue only exists on the windows toolchain because windows does not support rpaths and the the proc-macro server is now dynamically linked to something outside of its own directory. Latest nightly r-a and next week’s stable r-a should just work again.

This was fixed by https://github.com/rust-lang/rust-analyzer/pull/16312 (if not please tell)

From zulip thread above, the issue may result from this PR merged on 2024-01-05, so I tried pinning the nightly toolchain before that date, and with latest rust-analyzer v0.3.1799 released on 2024-01-08, it turns out to work without the error. And if your toolchain is on stable, you may not see this error, since that landed before 2024-01-05 (I’ve tested it on stable toolchain with latest nightly RA).

# rust-toolchain.toml in your project
[toolchain]
channel = "nightly-2024-01-04"

or

# globally override
rustup toolchain install nightly-2024-01-04
rustup default nightly-2024-01-04

P.S. it seems that this issue mainly happens on Windows.

We really need to improve the pipe closed error somehow