Allow specifying both project-wide and package-specific `clippy.toml` settings

[jplatte]

For Ruma, I would like to have both project-wide and package-specific .clippy.toml settings:

• msrv (and import_rename once it's available) as a project-wide setting
• Possibly a project-specific msrv override
• disallowed_type project-specific setting to disallow HashMap / HashSet use within proc-macros

It seems like this is not currently possible, with the first .clippy.toml found in one of the parent directories of the package being checked being used for all settings. Maybe an alternative to the current filesystem hierarchy based config lookup¹ would be to only search the package dir² and the workspace root³ for clippy configuration and make any settings in the former overwrite settings from the latter?

¹ which AFAIK has proved problematic for Cargo, with some people wanting to move certain settings to Cargo.toml for better reproducability
² CARGO_MANIFEST_PATH
³ workspace_root in the cargo metadata --format-version 1 output

[eholk]

Just to make sure I understand the algorithm you're proposing, let me try to restate it. Let's say you have a directory tree like this:

workspace/
    .clippy.toml
    project1/
        .clippy.toml
    project2/
        .clippy.toml

The idea is that when running clippy on project1, you'd first read workspace/.clippy.toml, and then read workspace/project1/.clippy.toml, with settings from project1/.clippy.toml overriding those in workspace/.clippy.toml when they both specify the same settings. Is this right?

This seems pretty reasonable, and in line with what a lot of other tools do.

For the sake of argument, what if instead we made this explicit by adding something like inherit = "../.clippy.toml" to project1/.clippy.toml and didn't do the implicit path search? Would the explicit approach be preferable or more flexible?

[jplatte]

@eholk That's exactly what I'm proposing, yes.

Sure, inherit would be more flexible – you could inherit settings even outside of workspaces, have multiple "base" configs if you want the same settings across a few but not all projects in a workspace and even define larger hierarchies of config files.

I suppose in Ruma this could be used to have a single .macros.clippy.toml that's used for all the macro crates. That would work even without explicit inheritance though, by symlinking that file into the macro crate dirs. So I think I would still prefer my original proposal rather than the customizable config inheritance. At least for me personally, it seemed like an obvious thing to try, whereas config inheritance would have to be prominent enough in the docs.

[eholk]

Thanks! I imagine the two approaches could work together if there was really a need for both, but it's probably better to get the simplest thing that works first.

rust-lang/cargo#5034 is probably relevant here as well.

[eholk]

Some other related issues:

• Allow/deny lints in clippy.toml #1313
• Add a file allowing cross-crate configuration of lints rust#45832

[severinrudie]

@rustbot claim

[severinrudie]

@rustbot release-assignment

😢 Sorry all

[Centri3]

I'd like to take a crack at this, @rustbot claim

[Centri3]

It's worth noting you can kind of do this already (I think) using .cargo/config.toml by setting CLIPPY_CONF_DIR. Not ideal though as 1, you'll need to add it to a new directory, 2, get a ton of warnings if you have a global clippy.toml, and 3, can't inherit. So this will still be very useful!