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 ➕1️⃣ 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 ➕💯 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.