Enable some lints and simplify CLIPPY=1
#566
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This simplifies a bit the
Makefile
and enables some extra lints:If some of these end up being too painful, we can always disable them later. But in general they sound like a good idea as long as they are not too annoying (i.e. an
allow
here or there). So far, most code "just worked". The only cases I had to change were:unreachable_pub
has found a few improvements already, and while its docs say it is pending some fixes on top, it seems good enough.let_unit_value
requires a small change for the unit guard, but I think it makes the code a bit more clear anyway.I am also contemplating always using the Clippy driver and let kernel developers get accustomed to it -- i.e. no
CLIPPY=1
anymore. This has the downside that it has a slight but noticeable performance penalty even if everything isallow
(I guess it is going through the AST on its own, i.e. independently ofrustc
, which I guess could be improved if it was integrated withrustc
instead). But it is not that big, so if Clippy upstream confirms there is no other downside apart from performance (rust-lang/rust-clippy#8035), then I think it may be the best path forward. In such a case, we could also consider moving some of them toW=
instead, and possibly enabling others in other groups too.