Open ssokolow opened 3 years ago
Thank you for your feedback!
It was our first attempt at research in this field, and we're delighted to see where we were not correct so that we can do it better.
I've checked the links you shared and agreed that approach based only on clippy.toml
is far from exhausive. We're currently thinking about performing a more complex analysis based on inline configs, and we would be glad to receive recommendations from experienced users.
Do you think analyzing inline configurations would be enough, or should we also parse configs of CI systems like Travis CI to determine which arguments people use while running Clippy?
Initially, I wouldn't have expected anything beyond inline configurations to be necessary but, after seeing how many people you found abusing cargo.toml
to "disable" lints, I now expect there probably is a non-trivial subset of users who do something like invoking cargo clippy
with -W/--warn
, -A/--allow
, -D/--deny
, and -F/--forbid
arguments via a justfile or Makefile
or cargo-make definition or CI configuration.
If this is used as described in your blog post, then you're operating under a false premise.
It is atypical to have a clippy configuration file because the configuration file is for configuring the lints, not enabling or disabling them, and most lints either have no configuration options or have good enough defaults.
In fact, you can't enable or disable lints in
clippy.toml
last I checked, and RFC 2476 was supposed to haveclippy.toml
made deprecated/unstable before it was distributed through rustup and rust-lang/rust-clippy#3013 tracks discussion of how to rectify that oversight in a non-breaking fashion.doc-valid-idents
is the only use I have forclippy.toml
in any of my projects but, if you take a look at my rust-cli-boilerplate starter template, you'll see that I go out of my way to enable extra Clippy lints.In fact, the
doc_markdown
lint (which, remember, is what consumesdoc-valid-idents
) is disabled by default.I didn't check exhaustively, but I didn't see any evidence that you're parsing the Rust code in the repositories to check for
allow
/deny
/forbid
attributes onclippy::...
warnings/errors and, without that, it's impossible to tell apart codebases which don't use Clippy from ones that do use it but leave the per-lint configuration keys at their defaults....not to mention that, if you're studying and giving advice on configuration changes away from default, it's much more meaningful to study which lints get enabled or disabled than configuration options that could even be dead weight if someone disabled the lint and didn't edit
clippy.toml
....and I can't think of a reason to do that legitimately, because that's equivalent to setting a regular expression for valid identifiers to
.*
instead of disabling the lint properly. Definitely a code smell, since it could easily fool any new developer coming to the project who checks the list of enabled and disabled lints without checkingclippy.toml
.