RA is broken for #[actix_rt::main] with proc macros enabled

[SomeoneToIgnore]

Cargo.toml:

[package]
name = "zzz"
version = "0.0.1"
edition = "2018"

[dependencies]
actix-rt = "1.1"
actix-web = "2.0"

main.rs:

#[actix_rt::main]
async fn main() -> std::io::Result<()> {
    let test = test();
    dbg!(test);
    println!("Hello, world!");
    Ok(())
}

#[derive(Debug)]
struct Test {
    test: i32,
}

fn test() -> Test {
    Test { test: 2 }
}

Enable proc macro and loadOutDirsFromCheck settings.

Expected: inlay hints present, highlighting works, completions proposed
Actual: very few RA features such as code lens are present, the rest is not working across the whole project

Here's how it looks with disabled proc macros:

Notice the hint and the highlighting.
When I toggle the proc macro checkbox and reload the server, I get this:

This happens in the code of a whole project, not only in the main.rs, making RA pretty useless.
Another interesting thing to notice that RA works fine with tokio:

[edwin0cheng]

Aiya, after some investigation, I ended up confirming the root cause of this bug:

There is a panic in actix_rt case:

thread '<unnamed>' panicked at 'can't resolve local ptr to SyntaxNode: SyntaxNodePtr { range: 160..329, kind: IMPL_DEF }', crates\ra_syntax\src\ptr.rs:30:28

It is caused by some proc-macro generated are inconsistent. I added some dbg! and here are two expansions expanded by the same struct. (by #[derive(derive_more::From)])

impl::core::convert::From<(h2::Error)>forConnectError{#[allow(unused_variables)]#[inline]fnfrom(original:(h2::Error))->ConnectError{ConnectError::H2(original)}}impl::core::convert::From<(SslError)>forConnectError{#[allow(unused_variables)]#[inline]fnfrom(original:(SslError))->ConnectError{ConnectError::SslError(original)}}impl::core::convert::From<(String)>forConnectError{#[allow(unused_variables)]#[inline]fnfrom(original:(String))->ConnectError{ConnectError::SslHandshakeError(original)}}impl::core::convert::From<(io::Error)>forConnectError{#[allow(unused_variables)]#[inline]fnfrom(original:(io::Error))->ConnectError{ConnectError::Io(original)}}impl::core::convert::From<(ResolveError)>forConnectError{#[allow(unused_variables)]#[inline]fnfrom(original:(ResolveError))->ConnectError{ConnectError::Resolver(original)}}

impl::core::convert::From<(ResolveError)>forConnectError{#[allow(unused_variables)]#[inline]fnfrom(original:(ResolveError))->ConnectError{ConnectError::Resolver(original)}}impl::core::convert::From<(String)>forConnectError{#[allow(unused_variables)]#[inline]fnfrom(original:(String))->ConnectError{ConnectError::SslHandshakeError(original)}}impl::core::convert::From<(SslError)>forConnectError{#[allow(unused_variables)]#[inline]fnfrom(original:(SslError))->ConnectError{ConnectError::SslError(original)}}impl::core::convert::From<(h2::Error)>forConnectError{#[allow(unused_variables)]#[inline]fnfrom(original:(h2::Error))->ConnectError{ConnectError::H2(original)}}impl::core::convert::From<(io::Error)>forConnectError{#[allow(unused_variables)]#[inline]fnfrom(original:(io::Error))->ConnectError{ConnectError::Io(original)}}

Noted that the orders of tokens are different, and it is due to the fact that derive-more crate is using HashMap such that this order is non-deterministic.

And we had some discussion for the general solution of this problem and I will start to study and implement a solution soon.

[bjorn3]

Even if there is a solution to this problem, derive-more should still be fixed to be deterministic. Otherwise crates using it have non reproducible builds. Maybe we should warn about non-deterministic expansions?

[edwin0cheng]

Yeah, I will submit an issue to them.

[SomeoneToIgnore]

Seems that there's exactly 3 usages of HashMap in their code: https://github.com/JelteF/derive_more/search?q=HashMap&unscoped_q=HashMap

hopefully, the PR to fix it will be small.

[edwin0cheng]

Upstream issue submitted, and if someone could write a blog post to call out people please don't use Hashmap in proc-macro, I will buy them a beer :)

[rayanmargham]

It is still happening on my machine, please reopen the issue

[Veykril]

What is the error you are getting, what rustc version and what rust-analzer version are you using?

[rayanmargham]

never mind I've fixed it