-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Rust-analyzer is extremely slow to index uom #7953
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
The crate in question uses a lot of (heavily recursive?) mbe macros so I imagine this might have been caused by #7513 |
Yeah, I think it is related to new mbe parser too. Still investigating what going on in Diesel case. |
Same for me. I've not yet seen rust analyzer complete indexing on my project, it's just stuck on uom. Reverting to 2021-02-01 fixes it |
#7994 may fix it. |
[triage] I tested it and it is not stuck now. However, there is some macro are not expanded correctly. Here is the test code : use uom::si::f32::*;
use uom::si::length::kilometer;
use uom::si::time::second;
fn main() {
let _length = Length::new::<kilometer>(5.0);
let _time = Time::new::<second>(15.0);
} |
Yes, see also: #6537 |
Since the perf issue was fixed, closing this in favor of #6537 |
I'm working on a project which uses the uom crate. Rust-analyzer was always very slow to index this crate, but recently it's become unusable. Rust-analyzer has been stuck, pinning one CPU, on "indexing: 87/596 (uom)" for a full hour, and none of its usual features work until indexing is complete.
(I'm afraid I don't know precisely when this happened; I haven't worked on this project much since November. It was usable then.)
It does eventually work - in fact, it completed indexing as I'm typing this bug report - but an hour-long start-up time is not a great user experience. The rust-analyzer process is also using 1.7GB of memory.
I'm using version 0.2.513 of rust-analyzer in VSCode 1.54.1.
The text was updated successfully, but these errors were encountered: