Both `cargo check` and `cargo clippy` one after the other in rust-analyzer

[frederikhors]

Hi everyone,

In my .vscode/settings.json I've configured cargo clippy as the default value for rust-analyzer.check.overrideCommand. While this gives useful linting, it significantly slows down feedback compared to cargo check, which is much faster.

Is there a way to combine both workflows? Ideally, I'd like fast feedback from cargo check and right after (and maybe only if there are NO errors) cargo clippy.

Is this possible with rust-analyzer or VS Code, and if so, how can it be configured?

What do you like?

[ChayimFriedman2]

AFAIK rust-analyzer supports streaming the errors from Cargo, so you can create a Cargo wrapper that calls them both and writes both results (but you may need coordination to handle them). That's probably a bad idea though.

Other than that, I don't believe r-a is going to officially support running both. Running one is already too slow for many, and has significant complexity in the r-a codebase.

[ChayimFriedman2]

Also note that the ideal solution is to make native r-a diagnostics which are instantaneous, usually. There are many of them already (although definitely not exhaustive), most are disabled by default (for having false positives, although for many the false positive rate is low today). You can enable them by setting "rust-analyzer.diagnostics.experimental.enable": true.

[frederikhors]

Are the r-a catching the errors like cargo-check does?

Anyway I'm asking to have a way to launch cargo check and only then cargo clippy and only if I want. Not by default for everyone.

Can we make this happen with a config?

[ChayimFriedman2]

Are the r-a catching the errors like cargo-check does?

Some of them.

Anyway I'm asking to have a way to launch cargo check and only then cargo clippy and only if I want. Not by default for everyone.

Can we make this happen with a config?

As I said:

Running one is already too slow for many, and has significant complexity in the r-a codebase.

So: too much implementation complexity, too little users who want this. My answer is no, but @rust-lang/rust-analyzer do you agree?

[frederikhors]

I mean I need something like:

"rust-analyzer.check.overrideCommand": [
    "cargo check",
    "&&",
    "cargo clippy"
],

Maybe this already works! I should try it.

[frederikhors]

cargo check failed to start: Cargo watcher failed, the command produced no valid metadata (exit code: ExitStatus(ExitStatus(1))): error: unexpected argument '&&' found

[ChayimFriedman2]

I understand what you want, and except for the ugly possible workaround that I posted in the beginning, I said that I don't want r-a to support this. But let's wait and see what other team members say.

[frederikhors]

Oh, got it - thanks so much for explaining. I think I could have been clearer on my end. I really appreciate all your hard work!

[ShoyuVanilla]

I haven't tried this yet by myself but I guess this would run cargo check first, and then cargo clippy.

"rust-analyzer.check.overrideCommand": "sh -c \"cargo check --workspace --message-format=json --all-targets && cargo clippy --workspace --message-format=json --all-targets\""

My take is:

• flycheck diagnostics are applied by stream, so even though you execute both commands, it only slows down the moment when they are completed. You'll get each diagnostics as soon as they are emitted from the commands
• And if you trigger another flycheck by saving a file, the previous job is cancelled, so the increased flycheck duration won't block your workflow, except it is consuming more system resources 😅
• And we even deduplicate flycheck diagnostics, so okay with having the same diagnostics from the clippy and normal check

But for the first bulletpoint, I think all the above thing might be pointless. We already applies the flycheck diagnostics incrementally. Will running cargo check and then cargo clippy speed up feedback loop, unless you run them parallel?