Proc macro server crashed

[Spanfile]

I don't think this is a duplicate of the other macro issues, I haven't seen this error message in them:

thread 'MacroExpander' panicked at 'assertion failed: `(left != right)`
  left: `0`,
 right: `0`', crates/proc-macro-srv/src/abis/abi_1_63/proc_macro/bridge/handle.rs:22:9
stack backtrace:
   0: rust_begin_unwind
             at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/core/src/panicking.rs:143:14
   2: core::panicking::assert_failed_inner
   3: core::panicking::assert_failed
   4: proc_macro_srv::abis::abi_1_63::proc_macro::bridge::handle::InternedStore<T>::new
   5: proc_macro_srv::abis::abi_1_63::proc_macro::bridge::client::HandleStore<S>::new
   6: proc_macro_srv::abis::abi_1_63::proc_macro::bridge::server::run_server
   7: proc_macro_srv::abis::abi_1_63::proc_macro::bridge::server::<impl proc_macro_srv::abis::abi_1_63::proc_macro::bridge::client::Client<(proc_macro_srv::abis::abi_1_63::proc_macro::TokenStream,proc_macro_srv::abis::abi_1_63::proc_macro::TokenStream),proc_macro_srv::abis::abi_1_63::proc_macro::TokenStream>>::run
   8: proc_macro_srv::abis::abi_1_63::Abi::expand
   9: proc_macro_srv::abis::Abi::expand
  10: proc_macro_srv::ProcMacroSrv::expand
  11: proc_macro_srv::cli::run
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Similarly to the other issues, the entire macro site is marked as an error with failed to write request: Broken pipe (os error 32).

Happens with at least all serde derives, tracing #[instrument], #[async_trait] and tonic's include_proto!.

rust-analyzer version: 0.0.0 (427061d 2022-06-19)

rustc version: rustc 1.63.0-nightly (bb8c2f411 2022-06-19) on Arch Linux

relevant settings: rust-analyzer.procMacro.attributes.enable is true, no macros have been ignored.

[lnicola]

Confirmed, looks like another ABI change. As a workaround you can downgrade to a nightly from around 2022-06-08.

[lnicola]

This broke between 2022-06-18 and 2022-06-19.

[bjorn3]

There are probably going to be a couple of other abi breakages in the near future. There are several PR's affecting libproc_macro open at the moment.

[dacut]

This workaround seems to work for me with VSCode:

1. Install rust-analyzer via rustup:

   % rustup +nightly component add rust-analyzer-preview

2. Get the path to the rust-analyzer nightly binary:

   % rustup which rust-analyzer
   /Users/dacut/.rustup/toolchains/nightly-aarch64-apple-darwin/bin/rust-analyzer

3. Add this to your VSCode settings.json, in the rust-analyzer.server.path setting:

   {
       "rust-analyzer.server.path": "/Users/dacut/.rustup/toolchains/nightly-aarch64-apple-darwin/bin/rust-analyzer"
   }

[flodiebold]

@dacut That's a different problem, caused by using an x86 VSCode and an ARM Rust toolchain. In that case, yours is indeed a possible workaround. (The other option would be to just install an aarch64 VSCode build.) This is unrelated to the problem in this issue though.

[dacut]

@flodiebold Where did you get the idea that I'm running x86 VSCode? I'm running ARM VSCode (from the Universal binary), ARM rust-analyzer, etc.:

% file /Applications/Visual\ Studio\ Code.app/Contents/MacOS/Electron
/Applications/Visual Studio Code.app/Contents/MacOS/Electron: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64
- Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64
- Mach-O 64-bit executable arm64]
/Applications/Visual Studio Code.app/Contents/MacOS/Electron (for architecture x86_64):	Mach-O 64-bit executable x86_64
/Applications/Visual Studio Code.app/Contents/MacOS/Electron (for architecture arm64):	Mach-O 64-bit executable arm64

% file ~/.vscode/extensions/rust-lang.rust-analyzer-0.4.1101-darwin-arm64/server/rust-analyzer
/Users/dacut/.vscode/extensions/rust-lang.rust-analyzer-0.4.1101-darwin-arm64/server/rust-analyzer: Mach-O 64-bit executable arm64

Same issue as here, with the failed to write request: Broken pipe (os error 32) resulting when rustup gets out-of-sync with the rust-analyzer binary.

[flodiebold]

@dacut It was a guess for the actual problem you're having, because the issue described here cannot be fixed by running another version of rust-analyzer. What's your rustc version, and what does the "Show RA Version" VSCode command say if you don't set rust-analyzer.server.path?

[dacut]

Hmm... it was suggested that ABI mismatches were at fault here from this Twitter reply by Lukas Wirth, hence my attempt to keep rust-analyzer in-sync with rustup.

Without rust-analyzer.server.path set, I currently get:

% rustc --version
rustc 1.63.0-nightly (5750a6aa2 2022-06-20)
> Rust Analyzer: Show RA version
rust-analyzer version: 0.0.0 (6fc5c3cd2 2022-06-20)

Interestingly, the version installed by rustup looks like it should be more broken... maybe?

% ~/.rustup/toolchains/nightly-aarch64-apple-darwin/bin/rust-analyzer --version
rust-analyzer 1.63.0-nightly (366bd7242 2022-06-12)

[flodiebold]

Ah yeah, the older version in rustup is likely just not showing the error message.

[Galster-dev]

Hello! I've been slowly downgrading using VS marketplace so I can tell this broke in release 0.4.1086
Downgrading to 0.4.1085 seems to fix this issue (there is other error log related to proc macro server which I'm not gonna cover because it's most likely already fixed)

[flodiebold]

@Galster-dev downgrading just hides the issue, it doesn't fix it. To hide it you could also just disable the diagnostic.

[dacut]

For those (like me) who might be curious as what to the proc macro PRs in flight might be that this issue depends upon (from #12600 (comment)), this is the list of PRs with "proc" in their title; what I found that seem to be relevant (recent):

• More proc macro tweaks rust#97445
• proc_macro/bridge: stop using a remote object handle for proc_macro Ident and Literal rust#98189
• proc_macro/bridge: remove client->server &HandleCounters passing. rust#98223
• proc_macro: Fix expand_expr expansion of bool literals rust#98463

That said, I'm about as far from an expert as one could be on proc_macro issues; this list is almost certainly inaccurate, but might provide some insight as to what's going on behind the scenes.

[lifegpc]

Got same error here.

[jonas-schievink]

#12747 should fix this issue, at least on beta and the current nightly. Please let us know if it still doesn't work.

[veber-alex]

Doesn't seem to work, I am getting the same assert as OP.
This is with
RA: rust-analyzer 0.0.0 (4cbf23c 2022-07-12)
Rust: rustc 1.64.0-nightly (38b72154d 2022-07-11)

[bjorn3]

I am pretty sure that rust-analyzer version doesn't yet include the fix.

[veber-alex]

well 4cbf23c is exactly the commit id of the fix.
Is the version number wrong?

[flodiebold]

Nightly indeed still seems to be broken, but beta is fixed. I think nightly already had some additional changes since beta branched (namely rust-lang/rust#98188).

[andylokandy]

Confirm fixed in the nightly build, but go-to-definition doesn't work for the idents inside the function-like proc macro. Maybe the ident span is get discarded.

[RohanKapurDEV]

I tried using @dacut's method to fix my issue, which did not work since I could not locate the rust-analyzer.server.path setting to begin with. I then tried to set rust-analyzer.procMacro.server to the same value (/Users/rohan/.rustup/toolchains/nightly-x86_64-apple-darwin/bin/rust-analyzer) but to no avail.

Running arm64 vscode on an m1 but r-a seems convinced im running on an x86 system. The error:

proc macro `main` not expanded: Cannot create expander for /Users/rohan/Desktop/code/autodca/target/debug/deps/libtokio_macros-71ca935c51905a5f.dylib: Io(Custom { kind: InvalidData, error: DlOpen { desc: "dlopen(/Users/rohan/Desktop/code/autodca/target/debug/deps/libtokio_macros-71ca935c51905a5f.dylib, 10): no suitable image found.  Did find:\n\t/Users/rohan/Desktop/code/autodca/target/debug/deps/libtokio_macros-71ca935c51905a5f.dylib: mach-o, but wrong architecture\n\t/Users/rohan/Desktop/code/autodca/target/debug/deps/libtokio_macros-71ca935c51905a5f.dylib: mach-o, but wrong architecture" } })rust-analyzer[unresolved-proc-macro](https://rust-analyzer.github.io/manual.html#unresolved-proc-macro)

Rust version: rustc 1.60.0 (7737e0b5c 2022-04-04)

[flodiebold]

@RohanKapurDEV make sure you're using the arm64 Rust toolchain if you're using arm64 VSCode (rustup toolchain install stable-arm64 && rustup default stable-arm64).

[RohanKapurDEV]

@flodiebold running that command yields the following error:

❯ rustup toolchain install stable-arm64 && rustup default stable-arm6
info: syncing channel updates for 'stable-arm64'
info: latest update on 2022-06-30, rust version 1.62.0 (a8314ef7d 2022-06-27)
error: target 'arm64' not found in channel.  Perhaps check https://doc.rust-lang.org/nightly/rustc/platform-support.html for available targets

Checking the provided link does lead me to a possible valid target: aarch64-apple-darwin. should i be using that instead of arm64?

[flodiebold]

Yes

[suica]

Switched my toolchain to beta and it worked.

[mccolljr]

I'm using rust toolchain nightly-2022-06-08 (as suggested higher up in this thread) with the latest release version of the rust-analyzer VSCode extension (0.3.1140-standalone (7e2b983fd 2022-07-24)). All VSCode settings for rust-analyzer are the defaults. This error (or a related error) is still occurring with this combination - what is the latest known-good pairing of nightly rust and rust-analyzer version? The atsamd-rs libraries make pretty heavy use of proc macros so I'm willing to use whatever tool versions necessary to have support until the larger issue here can be resolved.

The error message in question:

thread '<unnamed>' panicked at 'range end index 4 out of range for slice of length 0', library/core/src/slice/index.rs:73:5
stack backtrace:
   0: _rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::slice::index::slice_end_index_len_fail_rt
   3: core::ops::function::FnOnce::call_once
   4: core::intrinsics::const_eval_select
   5: core::slice::index::slice_end_index_len_fail
   6: proc_macro_srv::abis::abi_1_63::proc_macro::bridge::client::<impl proc_macro_srv::abis::abi_1_63::proc_macro::bridge::rpc::Decode<proc_macro_srv::abis::abi_1_63::proc_macro::bridge::client::HandleStore<proc_macro_srv::abis::abi_1_63::proc_macro::bridge::server::MarkedTypes<S>>> for &proc_macro_srv::abis::abi_1_63::proc_macro::bridge::Marked<<S as proc_macro_srv::abis::abi_1_63::proc_macro::bridge::server::Types>::TokenStream,proc_macro_srv::abis::abi_1_63::proc_macro::bridge::client::TokenStream>>::decode
   7: std::panicking::try
   8: std::panic::catch_unwind
   9: <proc_macro_srv::abis::abi_1_63::proc_macro::bridge::server::Dispatcher<proc_macro_srv::abis::abi_1_63::proc_macro::bridge::server::MarkedTypes<S>> as proc_macro_srv::abis::abi_1_63::proc_macro::bridge::server::DispatcherTrait>::dispatch
  10: <proc_macro_srv::abis::abi_1_63::proc_macro::bridge::closure::Closure<A,R> as core::convert::From<&mut F>>::from::call
  11: proc_macro::bridge::closure::Closure<A,R>::call
             at /rustc/5435ed6916a59e8d5acba2149316a841c3905cbd/library/proc_macro/src/bridge/closure.rs:30:18
  12: proc_macro::bridge::client::TokenStream::new::{{closure}}
             at /rustc/5435ed6916a59e8d5acba2149316a841c3905cbd/library/proc_macro/src/bridge/client.rs:263:27
  13: proc_macro::bridge::client::<impl proc_macro::bridge::Bridge>::with::{{closure}}
             at /rustc/5435ed6916a59e8d5acba2149316a841c3905cbd/library/proc_macro/src/bridge/client.rs:355:47
  14: proc_macro::bridge::client::BridgeState::with::{{closure}}::{{closure}}
             at /rustc/5435ed6916a59e8d5acba2149316a841c3905cbd/library/proc_macro/src/bridge/client.rs:312:17
  15: proc_macro::bridge::scoped_cell::ScopedCell<T>::replace
             at /rustc/5435ed6916a59e8d5acba2149316a841c3905cbd/library/proc_macro/src/bridge/scoped_cell.rs:74:9
  16: proc_macro::bridge::client::BridgeState::with::{{closure}}
             at /rustc/5435ed6916a59e8d5acba2149316a841c3905cbd/library/proc_macro/src/bridge/client.rs:310:13
  17: std::thread::local::LocalKey<T>::try_with
             at /rustc/5435ed6916a59e8d5acba2149316a841c3905cbd/library/std/src/thread/local.rs:445:16
  18: std::thread::local::LocalKey<T>::with
             at /rustc/5435ed6916a59e8d5acba2149316a841c3905cbd/library/std/src/thread/local.rs:421:9
  19: proc_macro::bridge::client::BridgeState::with
             at /rustc/5435ed6916a59e8d5acba2149316a841c3905cbd/library/proc_macro/src/bridge/client.rs:309:9
  20: proc_macro::bridge::client::<impl proc_macro::bridge::Bridge>::with
             at /rustc/5435ed6916a59e8d5acba2149316a841c3905cbd/library/proc_macro/src/bridge/client.rs:348:9
  21: proc_macro::bridge::client::TokenStream::new
             at /rustc/5435ed6916a59e8d5acba2149316a841c3905cbd/library/proc_macro/src/bridge/client.rs:256:17
  22: proc_macro::TokenStream::new
             at /rustc/5435ed6916a59e8d5acba2149316a841c3905cbd/library/proc_macro/src/lib.rs:129:21
  23: proc_macro2::imp::TokenStream::new
             at /Users/jmccollum/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-1.0.40/src/wrapper.rs:74:60
  24: proc_macro2::TokenStream::new
             at /Users/jmccollum/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-1.0.40/src/lib.rs:185:27
  25: modular_bitfield_impl::define_specifiers::generate
             at /Users/jmccollum/.cargo/registry/src/github.com-1ecc6299db9ec823/modular-bitfield-impl-0.11.2/src/define_specifiers.rs:9:5
  26: modular_bitfield_impl::define_specifiers
             at /Users/jmccollum/.cargo/registry/src/github.com-1ecc6299db9ec823/modular-bitfield-impl-0.11.2/src/lib.rs:19:5
  27: core::ops::function::Fn::call
             at /rustc/5435ed6916a59e8d5acba2149316a841c3905cbd/library/core/src/ops/function.rs:77:5
  28: proc_macro::bridge::client::Client<proc_macro::TokenStream,proc_macro::TokenStream>::expand1::{{closure}}::{{closure}}
             at /rustc/5435ed6916a59e8d5acba2149316a841c3905cbd/library/proc_macro/src/bridge/client.rs:438:44
  29: proc_macro::bridge::client::run_client::{{closure}}::{{closure}}
             at /rustc/5435ed6916a59e8d5acba2149316a841c3905cbd/library/proc_macro/src/bridge/client.rs:407:26
  30: proc_macro::bridge::scoped_cell::ScopedCell<T>::set::{{closure}}
             at /rustc/5435ed6916a59e8d5acba2149316a841c3905cbd/library/proc_macro/src/bridge/scoped_cell.rs:79:33
  31: proc_macro::bridge::scoped_cell::ScopedCell<T>::replace
             at /rustc/5435ed6916a59e8d5acba2149316a841c3905cbd/library/proc_macro/src/bridge/scoped_cell.rs:74:9
  32: proc_macro::bridge::scoped_cell::ScopedCell<T>::set
             at /rustc/5435ed6916a59e8d5acba2149316a841c3905cbd/library/proc_macro/src/bridge/scoped_cell.rs:79:9
  33: proc_macro::bridge::client::<impl proc_macro::bridge::Bridge>::enter::{{closure}}
             at /rustc/5435ed6916a59e8d5acba2149316a841c3905cbd/library/proc_macro/src/bridge/client.rs:344:35
  34: std::thread::local::LocalKey<T>::try_with
             at /rustc/5435ed6916a59e8d5acba2149316a841c3905cbd/library/std/src/thread/local.rs:445:16
  35: std::thread::local::LocalKey<T>::with
             at /rustc/5435ed6916a59e8d5acba2149316a841c3905cbd/library/std/src/thread/local.rs:421:9
  36: proc_macro::bridge::client::<impl proc_macro::bridge::Bridge>::enter
             at /rustc/5435ed6916a59e8d5acba2149316a841c3905cbd/library/proc_macro/src/bridge/client.rs:344:9
  37: proc_macro::bridge::client::run_client::{{closure}}
             at /rustc/5435ed6916a59e8d5acba2149316a841c3905cbd/library/proc_macro/src/bridge/client.rs:400:9
  38: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
             at /rustc/5435ed6916a59e8d5acba2149316a841c3905cbd/library/core/src/panic/unwind_safe.rs:271:9
  39: std::panicking::try::do_call
             at /rustc/5435ed6916a59e8d5acba2149316a841c3905cbd/library/std/src/panicking.rs:492:40
  40: ___rust_try
  41: std::panicking::try
             at /rustc/5435ed6916a59e8d5acba2149316a841c3905cbd/library/std/src/panicking.rs:456:19
  42: std::panic::catch_unwind
             at /rustc/5435ed6916a59e8d5acba2149316a841c3905cbd/library/std/src/panic.rs:137:14
  43: proc_macro::bridge::client::run_client
             at /rustc/5435ed6916a59e8d5acba2149316a841c3905cbd/library/proc_macro/src/bridge/client.rs:399:5
  44: proc_macro::bridge::client::Client<proc_macro::TokenStream,proc_macro::TokenStream>::expand1::{{closure}}
             at /rustc/5435ed6916a59e8d5acba2149316a841c3905cbd/library/proc_macro/src/bridge/client.rs:438:17
  45: proc_macro::bridge::selfless_reify::reify_to_extern_c_fn_hrt_bridge::wrapper
             at /rustc/5435ed6916a59e8d5acba2149316a841c3905cbd/library/proc_macro/src/bridge/selfless_reify.rs:64:17
  46: proc_macro_srv::abis::abi_1_63::proc_macro::bridge::server::<impl proc_macro_srv::abis::abi_1_63::proc_macro::bridge::client::Client<proc_macro_srv::abis::abi_1_63::proc_macro::TokenStream,proc_macro_srv::abis::abi_1_63::proc_macro::TokenStream>>::run
  47: proc_macro_srv::abis::abi_1_63::Abi::expand
  48: proc_macro_srv::dylib::Expander::expand
  49: core::ops::function::FnOnce::call_once{{vtable.shim}}
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
thread '<unnamed>' panicked at 'range end index 8 out of range for slice of length 0', library/core/src/slice/index.rs:73:5
stack backtrace:
   0: _rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::slice::index::slice_end_index_len_fail_rt
   3: core::ops::function::FnOnce::call_once
   4: core::intrinsics::const_eval_select
   5: core::slice::index::slice_end_index_len_fail
   6: <&str as proc_macro_srv::abis::abi_1_63::proc_macro::bridge::rpc::DecodeMut<S>>::decode
   7: proc_macro_srv::abis::abi_1_63::proc_macro::bridge::<impl proc_macro_srv::abis::abi_1_63::proc_macro::bridge::rpc::DecodeMut<S> for core::option::Option<T>>::decode
   8: proc_macro_srv::abis::abi_1_63::proc_macro::bridge::server::<impl proc_macro_srv::abis::abi_1_63::proc_macro::bridge::client::Client<proc_macro_srv::abis::abi_1_63::proc_macro::TokenStream,proc_macro_srv::abis::abi_1_63::proc_macro::TokenStream>>::run
   9: proc_macro_srv::abis::abi_1_63::Abi::expand
  10: proc_macro_srv::dylib::Expander::expand
  11: core::ops::function::FnOnce::call_once{{vtable.shim}}
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[jplatte]

The latest known-good pair is today's nightly of both rustc and rust-analyzer. And from now on, rust nightlies contain a rust-analyzer proc-macro server that is guaranteed to use the same proc-macro bridge version as rustc, which the rust-analyzer extension will check for and use (as of today), so expect no more breakage of this kind :)

You can read about all the details on fasterthanlime's blog.

[mccolljr]

The latest known-good pair is today's nightly of both rustc and rust-analyzer. And from now on, rust nightlies contain a rust-analyzer proc-macro server that is guaranteed to use the same proc-macro bridge version as rustc, which the rust-analyzer extension will check for and use (as of today), so expect no more breakage of this kind :)

You can read about all the details on fasterthanlime's blog.

Awesome news and of course also an awesome and informative blog post. Thanks for the answer+update & thanks to everyone who contributed for your work on this.

[SturdyFool10]

I have had the same issue, my code can be found at https://github.com/SturdyFool10/RustResourceMonitor.git, setup goes commit, cargo build, cargo run, it seems to only effect rust analyzer tho? it compiles and runs but that's still weird behavior, specifically my derive macro invocations on Serde::Serialize