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

[zjp-CN]

rust-analyzer version: rust-analyzer version: 0.3.1791-standalone (9db5155 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: #14991

[Veykril]

We really need to improve the pipe closed error somehow

[Veykril]

Though generally that means the server crashed I think, which has me worried that the upstream server is now built without the sysroot abi after the trouble i had there last week ...

[Veykril]

Yup, I broke the sysroot server last week ...

[Veykril]

apparently I managed to dynamically link the server against rustc internals? 🤨

[Veykril]

@onur-ozkan apologies for the cross-repo ping, but do you have an idea what could be going wrong here? Do I need to tell bootstrap to do static linking here somehow? Do you have an idea of how to go on about fixing this (problem being outlined below)?

[Veykril]

Oh, nvm now I see whats going on. We changed the tool mode to Rustc which is expected to dynamically link, but the proc-macro server lives in libexec, not bin so we fail to find the dylib! Well that is annoying ...

Unsure how to proceed here then, should we just move the server into the bin directory? Duplicating the libraries into libexec seems like a bad choice given their size, and symlinking isn't an option either I'd assume.

Alternatively, we could try linking in the rustc_driver statically for this, as we dont use as much of it as other tools are

[Veykril]

Started a discussion on zulip: https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/rust-analyzer-proc-macro-srv.20dynamically.20links.20rustc_driver

[nevercast]

Any updates to this? I'm seeing this with wasm_bindgen

[zjp-CN]

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.

[nevercast]

Thank you @zjp-CN. I will try that on my Windows machine. If the issue is not present on Linux I may also use that until it lands in latest nightly. Thanks for the quick and detailed response!

[Veykril]

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 #16312 (if not please tell)