Rust-analyzer doesn't check the buffer on typing, but only on save. How to change that?

Hi all!
I'm quite new to Rust and I'm learning it doing some exercises on Emacs. I use lsp-mode with rust-analyzer and rustic mode.
I noticed that RA checks the buffer only when I save the buffer, and not when I modify the file.
Since I'm a new user, I can only put one picture, to see the complete series of screenshots please see the issue I opened on GH.

For example, I have a file that gives me a warning (first picture on GH).

When I modify it I'd want to have the error to be "updated", however I get this:

Here it is reported a warning, but it works with non syntax-related errors too (say, incompatible types). Notice how Emacs doesn't receive notification of the new warning, so it keeps displaying it in the old position.

Instead, when I save the file RA correctly reprocesses it, and Emacs gives me the "updated" view (third picture):

This is, ideally, what I'd want from the beginning, every time the buffer is modified.

Is this a malfunctioning of RA? Is there a way to tune this behavior?
Thanks for your work!

No, it's because your system would likely grind to a halt if you did this and also opened a large rust project. Analyzing rust code can be quite resource intensive in both cpu time and RAM consumption.

Thanks, but I don't think that's the problem. The project I'm working on is a simple exercise from Advent of Code, say < 150 loc. Also, when I save my file, RA reprocesses it in a blink.

What I meant is, if they enabled analysis on every keystroke, it would be a performance footnuke¹.
While it might work for you right now, it would invariably blow up for anyone who had the audacity to open a "large enough" project, or just happened to hack their way into one for that matter.

¹The reason I call it a footnuke is that it wouldn't just blow up the analysis (and potentially editor) procs, it would grind your entire system to a halt, forcing a reboot.

1 Like

Uhm, I see. However, Emacs' lsp-mode offer a feature to check the file if idle after a customizable amount of time (defaults to 0.5s). Would it be possible to instruct RA to do so, i.e. run (I suppose) cargo check on demand?

I think this might be a good one for @matklad to weigh in on.

1 Like

This is not because of any performance considerations, but because these diagnostics are provided by running cargo check and rust-analyzer doesn't have any way of running cargo check on unsaved files.

rust-analyzer does have some diagnostics it computes itself, which do show up immediately (some of them are experimental and disabled by default). The plan is to provide all of them in this way, and the cargo check approach is just a stopgap until that's the case. It's still going to take some time though.


Can it be assumed that by the time all this is stable, the set of errors and warnings presented via RA is the same as the set presented by cargo check?

That is to say, not only the same number of errors/warnings, but at the same locations (this one seems obvious to me), with the same messages (this one does not)?

I don't know. It kind of depends on how the "librarification" effort proceeds; also the error messages and locations that rustc provides on the command line might not actually be the best fit for showing in the editor.

1 Like

Thanks, this explains the whole thing. If I wanted to try with the experimental feature, how should I proceed?

That's the rust-analyzer.diagnostics.experimental.enable setting (lsp-rust-analyzer-diagnostics-enable-experimental in Emacs). You can then also disable any that might be showing too many false positives with rust-analyzer.diagnostics.disabled.

Thanks! Right now it has no effect and indeed it seems it's unused, but I'll report to the lsp-team to troubleshoot it. Meanwhile, I'll wait for the new versions of RA. Thanks a lot for your work! :heart_hands:

If it doesn't exist for you, you might need a newer version of emacs-lsp. But don't expect too much, there are currently only a few experimental diagnostics. Try writing something like let x: u32 = "foo";, that should result in a type-mismatch error.

Thanks! Btw, it seems like clangd for C/C++ doesn't suffer from this (e-g-, type mismatches are reported real time). What architectural differences makes it possible?

header files: Three Architectures for a Responsive IDE

1 Like

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.