Option "Run external linter to analyze code on the fly" keeps saving files unexpectedly

[ivan-aksamentov]

Environment

• IntelliJ Rust plugin version: 0.4.158.4203-213
• Rust toolchain version: 1.56.1 (59eed8a2a 2021-11-01) x86_64-unknown-linux-gnu
• IDE name and version: CLion 2021.3 EAP (CL-213.5605.4)
• Operating system: Ubuntu 20.04
• Macro expansion engine: new
• Name resolution engine: new

Problem description

When "Run external linter to analyze code on the fly" is enabled, the current file is saved every time the linter is triggered (looks like it is after I stop typing, debounced).

This is unexpected and does not play well with build systems where file changes trigger rebuild, tests etc. (e.g. using cargo watch). The rebuilds in this case are triggered way too often, consume a lot of resources and the terminal contents blinking rapidly on the screen. This behavior basically makes the "Run external linter to analyze code on the fly" feature and watch- or hot-reload- based dev workflows mutually exclusive.

I'd say automatic save is not something that should come by default, and most people would not expect this to happen. I'd like to be able to enable the "Run external linter to analyze code on the fly" feature while avoiding file saves.

I understand that it might be a limitation of the linter's interface, for example if it only accept files. But maybe it is possible to pass a string buffer? Or perhaps, as a workaround, to create a file in a temporary location? All I care is for source files to not be modified without me hitting Ctrl+S.

I might be able to contribute. But a quick search for the flag name has shown a few places, but did not yield immediate location of where the save might happen. Can someone can give a pointer as to where to look in the codebase?

Steps to reproduce

• Tick "Run external linter to analyze code on the fly" option in plugin settings
• Open a Rust project and a Rust file in it
• Type something
• Notice that after you stop typing, the file is saved. To verify it:
  • Enable "Editor -> General -> Editor Tabs -> Appearance -> Mark modified (*)" to see that the tab marker which indicates unsaved changes disappears as long as the linter kicks-int.
  • Build project with cargo watch and see how it reruns every time you make a pause in typing.

Related:

• UI: Add a widget and some notifications for external linter #8018
• Allow annotating code with external linter on demand or add debounce option #4779
• Add option to run external linter on each save #5542

[vlad20012]

I'd say automatic save is not something that should come by default,

"Run external linter to analyze code on the fly" is not enabled by default btw

[vlad20012]

I understand that it might be a limitation of the linter's interface, for example if it only accept files. But maybe it is possible to pass a string buffer? Or perhaps, as a workaround, to create a file in a temporary location? All I care is for source files to not be modified without me hitting Ctrl+S.

The external linter (cargo check or clippy) works on a crate level, not file level, so it needs the entire crate to be passed/copied. In the case of cargo virtual workspace, it's needed to copy the entire workspace. This is not limited to only .rs files - the compiler (linter) can read any file because of include!() or include_str!() or include_bytes!() macro. Proc macros also can read any file during compilation (linting).

The solution could be making Cargo accept overwrites of some files (as string buffers or copies, as you proposed), but this requires changes in rustc and cargo. If you want to contribute, you can start there.

/summon @matklad

[ivan-aksamentov]

Thanks for explanation Vlad @vlad20012!

Sounds complicated. I am only an aspiring Rust programmer, so this task is probably too complex for me quite yet, as I don't know how all these parts of the Rust ecosystem work and my Rust time is only limited to weekends for now.

Also, I might be mistaken, but from my short interaction with Rust plugin in VSCode, I had an impression that there is no such problem (there are some others though). Maybe it's possible to "borrow" 😆 a solution from these folks? From what I remember, in VSCode there are 2 options to run Rust lints: via RLS or via rust-analyzer (which seems to be only available in nightly toolchains?). I am not sure which one CLion Rust plugin uses.

[vlad20012]

rust-analyzer works exactly like intellij-rust - it saves all files and executes cargo check. I'm not sure about RLS, but I admit it works differently because it links the entire compiler and can perform all analysis by itself. Anyway, RLS is deprecated and it will be dropped someday.

Btw there is an issue in rustc about such "filesystem overlay" rust-lang/rust#59976

[bjorn3]

The Rust plugin for vscode is backed by RLS, not rust-analyzer. RLS uses internal compiler interfaces to present a VFS to rustc. This requires it to be built using nightly and breaks once in a while. It also requires a recompile every time you change the rustc version you use. For this reason RLS is distributed as precompiled component using rustup.

[dan-lee]

This is still happening and I was quite surprised that it saves automatically by enabling this option.
An alternative would be to run cargo check or cargo clippy only on a save triggered by the user.
That would drastically bring down the re-runs for some projects

[abey79]

I'm running into the same issue with PyCharm, and this is particularly annoying because "Run external linter" triggers spurious saves in python files. Since I have Black as a file watcher, this is highly annoying.

For example, here, before I'm even able to type some content in my list, save -> black is triggered and I end up typing in the wrong place:

Export-1688051734956.mp4

[asnoeyink]

I'm running into a similar issue as @abey79 except the external linter is causing files in different projects to auto-save, which triggers all the file watchers unexpectedly. I would have expected the linter to only affect the files in its project, or just save .rs files.