Documentation on rust-analyzer seems outdated / anything to improve integration?

[bluenote10]

The section How do I get auto-completion with rust-analyzer? seems outdated, because rust-analyzer.cargo.loadOutDirsFromCheck no longer exists.

In practice this is impacting my productivity quite a lot, because auto-completion within a native class exported function doesn't seem to work at all. Often, my IDE is in a state reporting simply "all broken"

... and if this happens when I'm having a weak moment it can take a while to spot the actual error.

To avoid getting impacted by this issue I have now started to implement more complex methods as free floating functions like

fn process(this: &mut MyClass, delta: f64) -> Option<()> {
    // ...
}

and forward calls from the methods, which is of course unnecessary boilerplate.

---

To narrow down the problem we probably need to answer the questions:

1. Is this just something broken with my setup, or is everyone using rust-analyzer facing these issues?

2. If it is setup related, what are the tricks to get it going, which we could update in the book?

3. If it turns out that it is fundamentally not working, the question may be if we can do something on library / macro side to improve it. Following the links posted by the rust-analyzer maintainer leads to a similar issue for tokio-tracing, caused by the usage of syn and this proposal to solve it on their side. @Bromeon Is this proposal applicable to godot-rust as well?

[jacobsky]

@bluenote10 I agree, that part of the FAQ appears to be outdated. Thanks for creating the issue!

I have noticed similar issues occurring with the recent changes to Rust Analyzer, a lot of the issues appear to be related to rust-analyzer's macro expansion, so I ended up disabling them for the time being. I haven't noticed too many issues with rust analyzer though. It would be good to see what other folks using Rust Analyzer experience as well.

[Bromeon]

Does anyone who uses Rust-Analyzer have time to investigate this issue?
I can't say much about it as I'm on CLion.

3. If it turns out that it is fundamentally not working, the question may be if we can do something on library / macro side to improve it. Following the links posted by the rust-analyzer maintainer leads to a similar issue for tokio-tracing, caused by the usage of syn and this proposal to solve it on their side. @Bromeon Is this proposal applicable to godot-rust as well?

You mean design the macros in a way that they don't fail hard but allow to handle the error? Maybe, but if syn suffers from the same issue, it wouldn't help if we fixed anything on godot-rust side, would it?

[jacobsky]

@Bromeon I'm using Rust Analyzer, I'll doublecheck to see if there are any issues with a default install. It's been a while since I checked on my end.

[bluenote10]

It should be noted that this big related tracking issue on rust-analyzer side rust-lang/rust-analyzer#11014 has been closed recently, so perhaps things are much better in the meantime (hope I can re-check as well soon).

[jacobsky]

I re-checked this issue with default settings from Rust Analyzer and it doesn't seem to be impacting anything on my end anymore. @bluenote10 please feel free to re-open this issue if you see any issues.

[bluenote10]

@jacobsky I finally had some time to experiment with more recent rust-analyzer versions, and it looks like the issue with everything being underlined in red is indeed gone now.

What still isn't working for me is if you have e.g. use gdnative::prelude::Object; and you ctrl-click on Object. In this case I always end up here:

Do you get redirected to the actual implementation?

[Bromeon]

Reopen until clarified.