enable inheriting of `clippy.toml`

[oli-obk]

add a field to clippy.toml that allows it to refer to a git repository or a path where a clippy.toml is located. Pre-initialize all settings from the referred clippy.toml and then overwrite with the local clippy.toml.

Open questions:

• how to cache the downloaded clippy.toml
• is the referred clippy.toml allowed to refer to others itself?

[shepmaster]

Here's my ideal world:

Cargo.toml

[dev-dependencies]
clippy = "1.0.0"
clippy-integer32-preset = "2.1.8"
clippy-shepmaster-preset = "0.55.3"

clippy.toml

inherit-from = ["integer32", "shepmaster"]

# project-specific-settings

This is based on similar concepts from ESLint and Rubocop, both of which allow bundling up settings (and even additional lints!) from a reusable library.

[mcarton]

clippy-integer32-preset and clippy-shepmaster-preset would be dummy crates you publish just for their clippy.toml?
I kind of like the idea, but it's a little hacky.

[shepmaster]

just for their clippy.toml?

Probably, yes. However, I could also see a much smaller group of people producing their own Clippy lints this way. For example, there are Rubocop lints specific to RSpec, but which are produced by an unassociated third party.

it's a little hacky

The biggest benefits I see from this are:

1. Versioning
2. Reproducibility
3. Distribution

I think any solution that handles those would be a great one, leveraging the crates ecosystem is just the one that comes to mind based on the two examples I'm already familiar with.

you publish

Or reference from GitHub, or have a local directory, etc. Any of the normal Cargo distribution mechanisms.

[mcarton]

This is the kind of thing that could also be interesting for rustfmt.toml. Cc @rust-lang-nursery/rustfmt.

[mcarton]

Hum, that does not work, cc @nrc

[mcarton]

We need to decide what to do in case of conflict:

• for lists such as blacklisted-names, we can just merge them;
• for other types such as too-many-arguments-threshold, just error?

[oli-obk]

I think that the values that can't be merged should be overwritten

[mcarton]

If we overwrite values, this should come with at least a warning.