proc macro server crashed

[NickNick]

rust-analyzer version: b824588 2021-05-17 stable

After rustup update and maybe a new version of ra I get this error: 'proc macro returned error: proc-macro panicked: range end index 8 out of range for slice of length 0'.
stack backtrace:

thread 'main' panicked at 'range end index 8 out of range for slice of length 0', crates/proc_macro_srv/src/proc_macro/bridge/rpc.rs:135:1
stack backtrace:
   0: rust_begin_unwind
             at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/std/src/panicking.rs:493:5
   1: core::panicking::panic_fmt
             at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/core/src/panicking.rs:92:14
   2: core::slice::index::slice_end_index_len_fail
             at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/core/src/slice/index.rs:41:5
   3: <proc_macro_srv::proc_macro::bridge::server::Dispatcher<proc_macro_srv::proc_macro::bridge::server::MarkedTypes<S>> as proc_macro_srv::proc_macro::bridge::server::DispatcherTrait>::dispatch
   4: <proc_macro_srv::proc_macro::bridge::closure::Closure<A,R> as core::convert::From<&mut F>>::from::call
   5: proc_macro::bridge::closure::Closure<A,R>::call
             at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/proc_macro/src/bridge/closure.rs:27:18
   6: proc_macro::bridge::client::Literal::integer::{{closure}}
             at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/proc_macro/src/bridge/client.rs:244:25
   7: proc_macro::bridge::client::<impl proc_macro::bridge::Bridge>::with::{{closure}}
             at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/proc_macro/src/bridge/client.rs:336:47
   8: proc_macro::bridge::client::BridgeState::with::{{closure}}::{{closure}}
             at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/proc_macro/src/bridge/client.rs:293:17
   9: proc_macro::bridge::scoped_cell::ScopedCell<T>::replace
             at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/proc_macro/src/bridge/scoped_cell.rs:75:9
  10: proc_macro::bridge::client::BridgeState::with::{{closure}}
             at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/proc_macro/src/bridge/client.rs:291:13
  11: std::thread::local::LocalKey<T>::try_with
             at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/std/src/thread/local.rs:400:16
  12: std::thread::local::LocalKey<T>::with
             at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/std/src/thread/local.rs:376:9
  13: proc_macro::bridge::client::BridgeState::with
             at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/proc_macro/src/bridge/client.rs:290:9
  14: proc_macro::bridge::client::<impl proc_macro::bridge::Bridge>::with
             at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/proc_macro/src/bridge/client.rs:329:9
  15: proc_macro::bridge::client::Literal::integer
             at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/proc_macro/src/bridge/client.rs:237:17
  16: proc_macro::Literal::i64_unsuffixed
             at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/proc_macro/src/lib.rs:1006:21
  17: proc_macro2::imp::Literal::i64_unsuffixed
             at /home/nick/.cargo/registry/src/git.cakeli.workers.dev-1ecc6299db9ec823/proc-macro2-1.0.27/src/wrapper.rs:798:56
  18: proc_macro2::Literal::i64_unsuffixed
             at /home/nick/.cargo/registry/src/git.cakeli.workers.dev-1ecc6299db9ec823/proc-macro2-1.0.27/src/lib.rs:1045:41
  19: syn::expr::printing::<impl quote::to_tokens::ToTokens for syn::expr::Index>::to_tokens
             at /home/nick/.cargo/registry/src/git.cakeli.workers.dev-1ecc6299db9ec823/syn-1.0.72/src/expr.rs:3287:27
  20: derive_more::add_helpers::tuple_exprs
             at /home/nick/.cargo/registry/src/git.cakeli.workers.dev-1ecc6299db9ec823/derive_more-0.99.14/src/add_helpers.rs:11:20
  21: derive_more::add_assign_like::expand
             at /home/nick/.cargo/registry/src/git.cakeli.workers.dev-1ecc6299db9ec823/derive_more-0.99.14/src/add_assign_like.rs:21:17
  22: derive_more::add_assign_derive
             at /home/nick/.cargo/registry/src/git.cakeli.workers.dev-1ecc6299db9ec823/derive_more-0.99.14/src/lib.rs:280:29
  23: core::ops::function::FnOnce::call_once
             at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/core/src/ops/function.rs:227:5
  24: proc_macro::bridge::client::Client<fn(proc_macro::TokenStream) .> proc_macro::TokenStream>::expand1::run::{{closure}}
             at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/proc_macro/src/bridge/client.rs:410:40
  25: proc_macro::bridge::client::run_client::{{closure}}::{{closure}}
             at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/proc_macro/src/bridge/client.rs:377:26
  26: proc_macro::bridge::scoped_cell::ScopedCell<T>::set::{{closure}}
             at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/proc_macro/src/bridge/scoped_cell.rs:80:33
  27: proc_macro::bridge::scoped_cell::ScopedCell<T>::replace
             at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/proc_macro/src/bridge/scoped_cell.rs:75:9
  28: proc_macro::bridge::scoped_cell::ScopedCell<T>::set
             at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/proc_macro/src/bridge/scoped_cell.rs:80:9
  29: proc_macro::bridge::client::<impl proc_macro::bridge::Bridge>::enter::{{closure}}
             at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/proc_macro/src/bridge/client.rs:325:35
  30: std::thread::local::LocalKey<T>::try_with
             at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/std/src/thread/local.rs:400:16
  31: std::thread::local::LocalKey<T>::with
             at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/std/src/thread/local.rs:376:9
  32: proc_macro::bridge::client::<impl proc_macro::bridge::Bridge>::enter
             at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/proc_macro/src/bridge/client.rs:325:9
  33: proc_macro::bridge::client::run_client::{{closure}}
             at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/proc_macro/src/bridge/client.rs:370:9
  34: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
             at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/std/src/panic.rs:346:9
  35: std::panicking::try::do_call
             at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/std/src/panicking.rs:401:40
  36: __rust_try
  37: std::panicking::try
             at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/std/src/panicking.rs:365:19
  38: std::panic::catch_unwind
             at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/std/src/panic.rs:433:14
  39: proc_macro::bridge::client::run_client
             at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/proc_macro/src/bridge/client.rs:369:5
  40: proc_macro::bridge::client::Client<fn(proc_macro::TokenStream) .> proc_macro::TokenStream>::expand1::run
             at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/proc_macro/src/bridge/client.rs:410:13
  41: proc_macro_srv::proc_macro::bridge::server::<impl proc_macro_srv::proc_macro::bridge::client::Client<fn(proc_macro_srv::proc_macro::bridge::client::TokenStream) .> proc_macro_srv::proc_macro::bridge::client::TokenStream>>::run
  42: proc_macro_srv::cli::run
  43: rust_analyzer::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
thread panicked while processing panic. aborting.
[ERROR proc_macro_api::process] proc macro server crashed, server process state: Ok(Some(ExitStatus(ExitStatus(132)))), server request error: Os { code: 32, kind: BrokenPipe, message: "Broken pipe" 

Here's a minimal example: https://github.com/NickNick/ra-proc-macro-panic-derivemore-from

For me it looks like this:

... but runs fine:

nick@fusrodah /m/d/c/ra-proc-macro (main)> cargo r
warning: field is never read: `leg`
 --> src/main.rs:4:5
  |
4 |     leg: &'a str,
  |     ^^^^^^^^^^^^
  |
  = note: `#[warn(dead_code)]` on by default

warning: 1 warning emitted

    Finished dev [unoptimized + debuginfo] target(s) in 0.00s
     Running `target/debug/ra-proc-macro`
Hello, world!

[lnicola]

Works for me in rustc 1.54.0-nightly (5c0292654 2021-05-11), fails in rustc 1.54.0-nightly (5dc8789e3 2021-05-21).

The proc macro ABI strikes again.

[ivan]

For the confused (like me), this is not caused by building rust-analyzer with nightly, but rather your own project.

The last working version is nightly-2021-05-20 and the first failing version is nightly-2021-05-21.

[ctaggart]

Thanks @ivan. rustup default stable did the trick. 😅

[gilescope]

The solution is not to use nightly???

[lnicola]

Or to disable proc macro support.

[gilescope]

Turning proc macros off works. I've seen this on quite a few projects now. This seems a pretty widespread regression. Maybe proc macro should default to off for the moment as it could give a bad impression to new users - seeing a sea of red and them thinking they've done something wrong?

[lnicola]

I would assume that most new users aren't running nightly.

[gilescope]

For one reason or another, an awful lot of people are on nightly and their take away will be that something's up with RA because they're building fine with cargo. I think you're all doing a great job, I'm just concerned that this bug (rightly or wrongly) is making RA look flaky to a fair section of your userbase.

[flodiebold]

Disabling proc macros completely would have a far greater impact.

[adsick]

Hi guys, i'm getting this proc macro server crash... with my Rocket project, could you please tell me how to disable proc macros (i'm using VSCode)

[adsick]

ok, I figured it out

[danieleades]

I would assume that most new users aren't running nightly.

don't think this is a safe assumption.

• is this likely to be fixed soon?
• how likely is this regression (or a similar one) to appear again?
• what is the impact of disabling proc macros?

[lnicola]

is this likely to be fixed soon?

Right now we can't support multiple ABI versions, so we can't merge the open PR unit these nightlies hit stable

how likely is this regression (or a similar one) to appear again?

I'd guess there are about 3-4 breaking ABI changes per year.

what is the impact of disabling proc macros?

You won't get completions and other IDE features for code generated by proc macros.

[flodiebold]

Disabling proc macros will break a lot of functionality for stable users; it's not an option. We might want to think about supporting multiple ABI versions, or detecting nightlies with broken ABI and disabling proc macros for those; on the other hand, once we're following the Rust release train, we can just follow the nightly ABI.

@adsick that doesn't sound like a problem with our proc macro integration, since most errors are provided by cargo check, not our own analysis.

[gilescope]

hmm, I could think of a hack that might work: you have two release streams at the moment, a nightly rust analyser and a weekly one. If the nightly rust analyser was targeting the nightly abi that might be a resonable compromise?

[flodiebold]

That would mean supporting both ABIs anyway, so it would probably be almost as much work as just supporting both in the same build.

[zemelLeong]

Same issue in rustc 1.54.0-nightly (657bc0188 2021-05-31).

[flisky]

Could you elaborate, @gilescope ?

I tried the following steps, and no lucky -

• rustup upgrade to latest nightly
• clone the master & cargo xtask install & modify rust-analyzer.server.path settings
• reload vscode

[lnicola]

@flisky there's an open PR, but it might not be enough.

[flisky]

@lnicola actually I tried to build rust-analyzer on that patch, and it doesn't work for me. Anything goes wrong?

Edited: oh, maybe it's indeed not enough.

[lnicola]

It might be #9047 (comment), depending on your nightly version.

[gilescope]

@flisky clone the master & cargo xtask install was all I had to do as it installs it to the right location and then vscode just picked it up for me. (I'm on nightly by default)

[yotamofek]

Here's my fork with another commit that allows building for current nightly: https://github.com/yotamofek/rust-analyzer/tree/literal-from-str

[RagibHasin]

is this likely to be fixed soon?

Right now we can't support multiple ABI versions, so we can't merge the open PR unit these nightlies hit stable

how likely is this regression (or a similar one) to appear again?

I'd guess there are about 3-4 breaking ABI changes per year.

what is the impact of disabling proc macros?

You won't get completions and other IDE features for code generated by proc macros.

Having to wait for almost 3 months to get proc-macro working again, is really a sore point for me as most of the functions of one of my libraries are generated by proc-macros, and the library depends on nightly Rust. And if this happens 3-4 times a year (although I didn't notice such a thing last year) it would be broken most of the year. So, should rust-analyzer not support multiple ABIs.

If multiple ABIs is an option and needs help, I am happy to help out with some mentoring.

[dannymcgee]

(Quoted from #6755 (comment))

You can either:

use an older nightly
disable proc macros
use a stable toolchain

Would it be reasonable to include this information in the macro-error diagnostic message, or otherwise display some sort of actionable warning to the user? I use a library that's pretty reliant on proc macros, and for a while now (probably about as long as this issue has been open, come to think of it), I've been wondering why I wasn't getting correct type information in a lot of places. I'd been searching issues on this repo, hacking around the issue, and otherwise just suffering through it this whole time. In fact, I had previously even disabled the macro-error diagnostic from the RA settings because it was so pervasive, and I didn't know I could do anything about it (nor did I fully understand the consequences, i.e. the missing type information). Using stable is totally viable for me on most of my projects, I just didn't realize that would fix the problem I was having.

[sbrocket]

Just hit this myself. Agreed with the logic above that if multiple such breakages happen a year with a multi-month delay before the ABI changes can be merged to RA then it seems like RA with nightly will be unusable most of the year. I don't use nightly except when I have to, but it's not uncommon to run into an existing project/library that requires nightly for one reason or another. For example, I encountered this with https://github.com/serenity-rs/serenity which relies on unstable rustfmt features.

[lnicola]

@sbrocket you can use nightly rustfmt with cargo +nightly rustfmt.

[noxabellus]

FWIW, even if you disable proc macro support you can still get incorrect errors from this. Currently I have proc macro support disabled, and RA is giving me an error saying there is no method with a particular name on a type generated using proc macros, but the code compiles successfully.

[lnicola]

That's normal: since the macro didn't run, rust-analyzer can't know about the code it works have generated.

You can disable these diagnostics, but only globally -- there's no way to tell "this method would have been generated by a proc macro" without actually executing the said macro.

[noxabellus]

That's normal: since the macro didn't run, rust-analyzer can't know about the code it works have generated.

You can disable these diagnostics, but only globally -- there's no way to tell "this method would have been generated by a proc macro" without actually executing the said macro.

Actually I don't believe that is normally the case, is it? Usually errors relating to proc macro generated code are suppressed, otherwise any usage of proc macro code without the server would give an error. In any case, I suspect the error I was talking about was due to a separate issue, so probably best to disregard my comment for now.

[moxian]

FWIW, i believe this is currently hitting beta rustc release channel.

[mati865]

^ it is and will hit stable on 29-07-2021, then it'll be fixed to work with the new stable. Beta and nightly will work as well unless they get proc-macro changes again.

[lnicola]

Actually I don't believe that is normally the case, is it? Usually errors relating to proc macro generated code are suppressed, otherwise any usage of proc macro code without the server would give an error.

And it does.

[Dessix]

Having to wait for almost 3 months to get proc-macro working again, is really a sore point for me as most of the functions of one of my libraries are generated by proc-macros, and the library depends on nightly Rust. And if this happens 3-4 times a year (although I didn't notice such a thing last year) it would be broken most of the year. So, should rust-analyzer not support multiple ABIs.

Is there a way we could handle this sort of ABI change in the future by having two channels for rust-analyzer, one that only reflects the stable API, and one for the ABI in the latest nighly? It's not as elegant as supporting multiple on the fly, but it would at least allow nightly-only / nightly-primary users like myself to keep up to date, and could be overridden in per-workspace configurations.

[lnicola]

Fixed in #9550.