Checking an exercise takes too long

[GlowCheese]

Description

This is the video that the issue happens:

https://github.com/user-attachments/assets/00adc400-8e44-4899-9646-a7cff18bd7aa

It can be shown that every time I update the code of an exercise, the rust-analyzer builds the whole exercises folder (it has like 156 exercises and the extension run the code check for every single of them). During this process, I cannot use any command (h, n, l or q). Only after it finishes, rustlings tells me if my solution is correct or not and directs me to the next exercise.

I don't think it's a bug, but rather a code design issue. If I turn of rust-analyzer, it seems the issue's gone but I still have to wait for like 1-2 seconds for rustlings to detect file changes.

Please look into this issue and fix it. Thanks!

System Information

• OS: Windows 10 x64 (10.0.19045)
• VSCode: version 1.19.0
• rust-analyzer: 0.3.2062
• rustlings: 6.1.0

[mo8it]

Could you please show what plugins you have installed in VS-Code and whether you have any special configuration for rust-analyzer?

Rustlings detects a change and attempts to rerun the exercise. But if rust-analyzer is rebuilding the project, then cargo is blocked. Noramally, it doesn't take longer than one second to run the exercise.

It seems like a rust-analyzer problem.

Are you using WSL?

[GlowCheese]

I installed many plugins alongside with rust-analyzer. I tried disabling all of them and doing exercises but the issue still happens.

Do I have any special configuration? Nope, haven't opened rust-analyzer's extension settings before.

I'm not sure it's due to rust-analyzer problem or not. Tried 4 recent versions of rust-analyzer and none of them fixes the issue.

I'm not using WSL.

[mo8it]

I reported it in the Rust-Analyzer repo: https://github.com/rust-lang/rust-analyzer/issues/17829

Until this is fixed, I will add a line print showing that Rustlings is running an exercise (not just frozen) and then make a release.

[senekor]

I for one cannot reproduce this. At least rust-analyzer is snappy enough that it isn't obviously an issue on that side. It takes a fraction of a second for me.

(Although I'm not 100% sure how to verify if rust-analyzer rebuilt only one binary or all of them.)

I'm on Linux with a 12th gen Intel laptop cpu (i5-1240P).

[GlowCheese]

I reported it in the Rust-Analyzer repo: rust-lang/rust-analyzer#17829

Thanks you so much for handling this issue for me. I'll keep an eye on it to see if I can help with anything!

[mo8it]

A message is now shown to indicate that an exercise is being checked so users know that they just need to wait. You can update to the new version using the following two commands:

rustup update
cargo install rustlings

The actual issue needs to be fixed in Rust-Analyzer now.

[BreadlyUwU]

I think disabling "Check on Save" is a good workaround for now. You can temporarily disable it from VSCode's status bar:

[imaazkhalid]

I had the same issue on vscode and zed, checked zed's docs Here's what fixed the issue for me

https://zed.dev/docs/languages/rust#large-projects-and-performance

[alibektas]

This issue can be closed btw :)

[mo8it]

@alibektas I am afraid that this issue isn't fixed yet. You might have fixed one part of it, but Rust-Analyzer still seems to invalidate everything and check. Here is a video from a Windows VM with only 2 CPU cores.

Screencast from 2024-09-13 13-41-41.webm

At the beginning of the video, Rust-Analyzer is fully initialized and shows 168 errors and 26 warnings. Then, I press CTRL + s to save the current file without editing it. The number of errors and warnings goes to 0 and then goes up again while Rust-Analyzer says that it is running cargo check. What is it doing here?

After it is done, I edit the file by adding a to the body of the function. The same thing happens again, all errors and warnings are collected again. Towards the end, Rust-Analyzer shows cargo check: if1. if1 is the binary of edited file. So Rust-Analyzer doesn't say that it is checking everything, it only says that it checks the edited binary. But what happens before when only cargo check is displayed? Why does it invalidate all diagnostics and collect them again? Why does it take so long?

I tested it with the stable Rust-Analyzer extension from 09.06. and the pre-release one from 09.12.

This behavior is the same as in the video in the issue description. So I wonder whether https://github.com/rust-lang/rust-analyzer/pull/17912 is applied yet and if it has any effect?

[mo8it]

The related issue is now https://github.com/rust-lang/rust-analyzer/issues/18110

[daniel-pfeiffer]

One issue is that rust-analyzer checks way to much here. That is annoying, but would just be a waste of cpu if it were not for the blocking.

The other issue is that rust-analyzer defaults to working in the same target-dir as regular cargo. Alas the way rustlings works makes this more horrible than ever. Turns out the solution is to switch rust-analyzer.cargo.targetDir from null to true (in VS code settings.)

[mo8it]

Turns out the solution is to switch rust-analyzer.cargo.targetDir from null to true (in VS code settings.)

@daniel-pfeiffer Thanks for the suggestion! This doesn't solve the issue of Rust Analyzer checking too much. But at least it stops it from blocking Rustlings!

I added it to the config generated during the initialization: https://github.com/rust-lang/rustlings/commit/e76ca5e2b97f0b7b292bbe504debb42ec7b36a87 Unfortunately, rust-analyzer.toml is currently broken: https://github.com/rust-lang/rust-analyzer/issues/13529 This means that people need to apply this workaround manually for their editor :/

Rust Analyzer should either fix the issue itself or at least fix rust-analyzer.toml @Veykril @alibektas 🤍