--keep-going with cargo clippy

I have a project with a library and two binaries (GitHub - Linutronix/detnetctl: A TSN/DetNet Node Controller with Interference Protection).
My current observation with cargo clippy is that if there is a lint that generates an error, the binaries are not checked by clippy. Of course, for the compiler itself it makes sense not to try to compile the binary if the library has errors, but for clippy that seems unexpected to me and especially for a CI it would be nice to have all linter errors from both the library and the binaries already in the first run.

I currently use

cargo clippy --all-targets -- -D clippy::all -D clippy::pedantic

I found

--keep-going Do not abort the build as soon as there is an error
but apparently it does not change the behavior in my situation.

What is the reason for this behavior?

Just checked locally and I get the same behaviour. Both for cargo clippy and cargo check. It looks to me that --keep-going could be a little better documented on when it is applied. See this comment by David Tolnay on the tracking issue for --keep-going:

especially this paragraph (emphasis added by me):

Some of these rustc executions need to be serial, for example if one has an input rlib/rmeta artifact that is the output of the other. Some rustc executions can be done in parallel because neither one produces artifacts that are a transitive dependency of the other. Some rustc executions that can happen in parallel, are done serially anyway, because there are not enough cores on the machine to serve the inherent parallelism in the build graph.

Your binaries depend on the rlib/rmeta artifact from your library. If building your library returns an error of any kind (including lints you set to be denied), no rlib/rmeta gets generated. Due to this dependency, your binaries can't be build, even if you specify --keep-going.

1 Like

Thanks a lot! I totally get why it is not possible to compile the binary without the artifact of the library build. But I was expecting that clippy (as static code analyzer) does not require any artifact from the previous step (in this case linting the library), but apparently my assumption is wrong?

1 Like

I'm not familiar with how clippy works internally. What I can gather from quickly glancing at the source of cargo-clippy, the binary executed when you run cargo clippy, it starts a child process that either runs cargo check or cargo fix, both of which compile your code.

I see. It probably does not make sense to run the linter itself, if the code does not compile, because it would require to enable the linter to not go crazy for invalid code. And for checking that, the code needs to be compiled and for that we need to compile the dependencies, I see...

Ok, then there is probably not much I can do about that (before anyone implements the suggestions in the discussion linked by you).

1 Like

It's not just about “the code compiles” as a sanity check. It's also that in order to understand the code enough to produce lints, information is needed about the items used in the code — including items from dependencies.


Presumably the best way to --really-keep-going is to simply set Clippy to warn rather than deny and configure CI to fail the build if there are warnings.