rust-analyzer: proc macro server crashed
rust-analyzer version: b82458818 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/github.com-1ecc6299db9ec823/proc-macro2-1.0.27/src/wrapper.rs:798:56
18: proc_macro2::Literal::i64_unsuffixed
at /home/nick/.cargo/registry/src/github.com-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/github.com-1ecc6299db9ec823/syn-1.0.72/src/expr.rs:3287:27
20: derive_more::add_helpers::tuple_exprs
at /home/nick/.cargo/registry/src/github.com-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/github.com-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/github.com-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!
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 24
- Comments: 42 (25 by maintainers)
Commits related to this issue
- Downgrade nightly to 2021-05-20 to fix proc macro server crash in rust-analyzer https://github.com/rust-analyzer/rust-analyzer/issues/8925 — committed to LucasPickering/terra-rs by LucasPickering 3 years ago
- Downgrade nightly to 2021-05-20 to fix proc macro server crash in rust-analyzer https://github.com/rust-analyzer/rust-analyzer/issues/8925 — committed to LucasPickering/terra-rs by LucasPickering 3 years ago
- Workaround https://github.com/rust-analyzer/rust-analyzer/issues/8925 — committed to dudykr/stc by kdy1 3 years ago
- Merge #9550 9550: Proc macro multi abi proof of concept r=matklad a=alexjg #8925 was irritating me so I thought I would have a bash at fixing it. What I've done here is copy the `crates/proc_macro_s... — committed to rust-lang/rust-analyzer by bors[bot] 3 years ago
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-analyzernot support multiple ABIs.If multiple ABIs is an option and needs help, I am happy to help out with some mentoring.
ok, I figured it out
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-20and the first failing version isnightly-2021-05-21.I would assume that most new users aren’t running nightly.
Fixed in #9550.
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.
(Quoted from https://github.com/rust-analyzer/rust-analyzer/issues/6755#issuecomment-852734374)
Would it be reasonable to include this information in the
macro-errordiagnostic 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 themacro-errordiagnostic 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.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
stableAPI, and one for the ABI in the latestnighly? 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.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.
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.Right now we can’t support multiple ABI versions, so we can’t merge the open PR unit these nightlies hit
stableI’d guess there are about 3-4 breaking ABI changes per year.
You won’t get completions and other IDE features for code generated by proc macros.
Works for me in
rustc 1.54.0-nightly (5c0292654 2021-05-11), fails inrustc 1.54.0-nightly (5dc8789e3 2021-05-21).The proc macro ABI strikes again.
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.
And it does.
@flisky clone the master &
cargo xtask installwas 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)Same issue in
rustc 1.54.0-nightly (657bc0188 2021-05-31).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?
don’t think this is a safe assumption.
Disabling proc macros completely would have a far greater impact.
Or to disable proc macro support.
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.
Thanks @ivan.
rustup default stabledid the trick. 😅