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)

[spvky]

Don't know if this is 100% related but I'm running the stable-x86_64-unknown-linux-gnu toolchain and using rustup update to update to rust 1.76 yesterday introduced this error using the built in LSP in nvim

[arnfaldur]

I have also encountered this exact issue using lsp-mode in emacs on linux. I managed to mitigate it by using an older toolchain (from around last october) but I can't use the old toolchain anymore, reintroducing the problem.

[zjp-CN]

@spooky-th-ghost I've tested 2024-02-12 nightly RA with 1.76 stable toolchain (released on 2024-02-04) for proc macros, nothing goes wrong.
IIUC the error says your proc-macro server (from toolchain) is newer than RA. What's the verion of your RA?

[Veykril]

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

[arnfaldur]

I was having issues with making lsp-mode in emacs use the matching rust-analyzer and proc macro expander. I just messed with it until it worked.

[spvky]

@spooky-th-ghost I've tested 2024-02-12 nightly RA with 1.76 stable toolchain (released on 2024-02-04) for proc macros, nothing goes wrong. IIUC the error says your proc-macro server (from toolchain) is newer than RA. What's the verion of your RA?

I pulled the source yesterday and built and it looks like it's version 0.0.0

[spvky]

Just downloaded the release of rust-analyzer from today and i'm still getting the same issue on proc-macros

[Veykril]

Then it seems like you are still somehow running an outdated server as the release build has the latest server version running.

I pulled the source yesterday and built and it looks like it's version 0.0.0

source builds always have version 0.0.0

[spvky]

pretty lost at this point, reinstalled rustup and rust analyzer and I'm still getting the error, my current rust-analyzer version is rust-analyzer 0.3.1850-standalone

[benfaerber]

I'm having the same issue on Neovim on Pop OS (Linux).
rustc 1.76.0 (07dca489a 2024-02-04)
rust-analyzer 1.76.0 (07dca48 2024-02-04)

proc macro Serialize not expanded: Failed to run proc-macro server from path /home/ben/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/libexec/rust-analyzer-proc-macro-srv, error: Custom { kind: Other, error: "proc-macro server's api version (3) is newer than rust-analyzer's (2)" }

I've tried everything, reinstalling, rebooting, replacing the rust-analyzer binary with the latest release.

[zjp-CN]

@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.

[benfaerber]

@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.

OMG I didn't realize that! Thanks for the tip, it fixed it!

[790944715]

Is this issue been fixed?
I still encounter this issue with the stable version:

**PS F:\workspace\rust\test-ra> rustup update
info: syncing channel updates for 'stable-x86_64-pc-windows-msvc'
info: checking for self-update

stable-x86_64-pc-windows-msvc unchanged - rustc 1.77.2 (25ef9e3d8 2024-04-09)

info: cleaning up downloads & tmp directories**

Here's the error message, how can I fix this issue in vscode, currently can't find a useful way.
proc macro Parser not expanded: failed to write request: 管道正在被关闭。 (os error 232)

[TheRealSmeddy]

Updated rust version, restarted the workspace and extensions, seems to be fixed

[Zerowalker]

EDIT:

Ignore this, for some reason proc macro was disabled in the settings,
no clue why it has worked before though, but enabling it made it work as intended, my bad

I still get this issue:

stable-x86_64-pc-windows-msvc (default)
rustc 1.79.0 (129f3b996 2024-06-10)
---
Version 0.4.2039, Server Version 0.4.2039-standalone (26747bd1e 2024-07-16)
or
Version 0.3.2037, Server Version 0.3.2037-standalone (e9afba57a 2024-07-14)

Have updated rust and reloaded the workspace, even restarted vscode to no avail.

[KiSetsuFu-PuLiN]

Fixed after update VSCode