Rust-clippy: Allow/deny lints in clippy.toml

[BenjaminGill-Metaswitch]

I'm currently trying to use Clippy for a large multi-crate project. An issue I've found is enabling additional lints: if I want to enable missing_docs_in_private_items, I've got to add #![allow(unknown_lints)] and #![warn(missing_docs_in_private_items)] to every main.rs and lib.rs (i.e. >10 places).

It would make clippy more usable for large projects if one could allow/deny/warn lints in clippy.toml, e.g.

warn = ["missing_docs_in_private_items"]

[oli-obk]

For cargo clippy this is easy. I'm not sure what to do in the plugin case though

[BenjaminGill-Metaswitch]

For comparison, Rustc allows one to set warning levels via environment variable: RUSTFLAGS="-W missing_docs".

Cargo then has a config file (.cargo/config), in which you could put the following:

[build]
rustflags = ["-W", "missing_docs"]

As I understand the way Cargo works, Cargo uses this config to construct the RUSTFLAGS environment variable and pass it into Rustc.

Might it be possible to do something similar for Clippy?

[Manishearth]

We can do the same for cargo clippy, but not the clippy plugin.

[casey]

@BenjaminGill-Metaswitch: Would my suggestion in #1340 be good enough? This would also make it clear that this can be done with cargo clippy, but not the plugin, since only cargo clippy parses command line options.

[mcarton]

@casey The problem with command line options is that you need to retype them every time (or find them in you shell's history), and you need to document them for other users. Having this persistent in a conf file would be more convenient.

[rajatgoel]

It would be great if clippy.toml supports overriding levels too (as suggested in the original in this issue). We are in the same boat, tons of crates (100+ at the moment) and we would like to share same setting across them.

cargo clippy solution doesn't work for us because we directly use rustc (via bazel) to build these crates.

[pravic]

+1.

It would be nice to have all lint settings in clippy.toml. But I would place each lint at separate line:

absurd_extreme_comparisons = "warn"
almost_swapped = "warn"
assign_ops = "allow"
needless_return = "allow"

instead of

warn = ["absurd_extreme_comparisons", "almost_swapped"]
allow = ["assign_ops", "needless_return"]

Because it would be hard to maintain (especially via VCS) long lists of settings.

[laumann]

I would like to add my :heavy_plus_sign::one: here as well. I used clippy here and with a few example programs I had to add individual cfg_attr in a few places (see this commit).

I would like to have both options from @pravic's suggestion. For my current use case, I would go for the latter form with:

allow = ["ptr_arg", "type_complexity", "needless_pass_by_value", "many_single_char_names"]

but I can see how both forms could be useful (resolving the use of both forms might be more complex though).

EDIT I'll also add my :heavy_plus_sign::100: for clippy being a great tool - and easy to use!

[gnzlbg]

Ideally cargo clippy would try to find the clippy.toml file located in the closest parent directory of the file being processes. That way one can have a clippy.toml in the root of a project that would apply to all modules and crates in that project, while still allowing using a different clippy.toml for a particular sub-crate / sub-module, for example, for the examples/ directory in a library crate.

The clippy.toml could include an option to tell cargo clippy to find the "parent" clippy.toml file to that one as base, and apply the current options as an override.

---

EDIT: sed s/clippy/cargo clippy/

[oli-obk]

Isn't this something rustc/cargo should provide? Lints aren't something clippy-specific. Allowing/denying them is currently only possible with attributes, I don't see why we couldn't have a --lint-file=foo.toml option on rustc which is auto-filled by cargo if a lints.toml exists.

[gnzlbg]

Sorry! By clippy above I meant cargo clippy, I never use clippy (nor the clippy plugin) directly.

[oli-obk]

@gnzlbg I wasn't specifically targeting your comment. This entire issue feels, after re-reading it, like it should be part of rustc, not clippy, not even cargo clippy. There are probably rustc lints that one would like to enable across all projects.

[gnzlbg]

Makes sense, is there an issue filled about this in rustc?

[oli-obk]

There is now: https://github.com/rust-lang/rust/issues/45832

[phansch]

This is now tracked in cargo: https://github.com/rust-lang/cargo/issues/5034

[phansch]

Going to close this as there's nothing to be done on the Clippy side currently.

[dansgithubuser]

This was closed two years ago and the descendent issue (https://github.com/rust-lang/cargo/issues/5034) is inconclusive and hasn't had an update since November.

Am I underestimating how easy it is to get this in to clippy? Can we save everyone the pain of waiting for this feature somewhere else by writing some temporary code?

Edit: writing a custom cargo clippy invocation into a custom script solves for my use case.

Edit: allow flags not working, not sure why...

[flip1995]

It would be easier to implement this in cargo, instead of in Clippy. There's not really a reason, why this should first be implemented in Clippy, instead of directly in cargo. Clippy is not a temporary-test-code repository ;)

[dansgithubuser]

It's a piece of software with features that users use. Right now it doesn't have a feature because it's punted to someone else and they are moving slow (and cargo should move slow because it's so core).

I completely accept that time is limited, but seemed to me like this had been forgotten, or maybe more sensible workarounds had been found but not collected here.

[flip1995]

What I wanted to say is, that it wouldn't make sense for someone who wants to implement this, to start here in Clippy. If someone wants to put time into this, then it should be done directly in cargo.

IIUC the feature was accepted in the cargo repo. Now someone has to step forward and implement this. There's no point in writing throwaway code for an accepted feature. It wouldn't be easier to implement this in Clippy either.

[pravic]

We already have clippy.toml with some configuration, why move it to the Cargo.toml (which is complicated enough already)? AFAIK, rustfmt.toml is still a separate file - and rustfmt and clippy are separate tools also.

[flip1995]

clippy.toml is for configuration of Clippy lints, not enabling/disabling lints during compilation (decided in the Clippy 1.0 RFC). The lint configuration should not be included in the Cargo.toml, but in a lints.toml (or similar). This requires a toml parser for the lint enabling/disabling syntax. For this, it doesn't matter if the parser is implemented in Clippy or cargo. By implementing it in cargo we can control lints not only from Clippy, but also rustc (and possibly other lint tools in the future).