With my rather small testingt project, when depending on iced 0.12.0, iced_wiget 0.12.0, iced_runtime 0.12.0 und iced_aw 0.7.0 lokally installed, after starting VS code, the rust analyzer takes 20 miutes to scan the project. During that time, working is close to impossible.
It not only eats CPU and blocks the directories the user commands need, but it also miracolously causes that some 100 crates need to be recompiled when I do cargo check, run, …
On top of this, very often, the analyzer starts a long scanning session again when I just save main.rs.
Make sure your Rust Plugin for VSCode is up-to-date
Make sure your Rust tooling is up-to-date
Once you get all this done and the issue persists I believe you have two options:
Look-up for possible new (or known) issue related to VSCode’s Rust Plugin and the rust-analyzer
Look-up for documentation on how to adjust the VSCode’s Rust Plugin to be “less aggressive” a.k.a: not trigger periodically, not trigger when opening a window/project.
In resume. Seems to not be related to iced itself. Unless this scenario is happening ONLY with iced based projects I would recommend pursuing the answer on other forums.
VS Code and Rust analyzer are the latest released versions.
Rustc is the current beta (Yesterday I read that the new nightly is supposed to be a lot faster. … downloading …)
IMHO It definitvely is a bug that rust analyzer in some way confuses the make process so that some crates get re-compiled when I do “cargo r” etc.
In fact it would be best if any crates could optionally could be handled as pure binaries. That would speed up the make process and prevent the analyzer from doing too much nonsense.
Does cargo privide such options ?
(Of course you are right: this very likely is not related to iced at all. But it might be of interest for other who use iced in their projects and hit the same problems. )
)