New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clippy 1.0 #2476

Open
wants to merge 17 commits into
base: master
from

Conversation

Projects
None yet
@Manishearth
Member

Manishearth commented Jun 14, 2018

This RFC proposes a Clippy 1.0 in preparation for being shipped via Rustup. It aims to get community consensus on the current state of Clippy lints, as well as on what lints we should uplift to the compiler directly if any.

See also: The Future of Clippy

Co-written by @oli-obk

Rendered

Manishearth and others added some commits Jun 14, 2018

Merge pull request #2 from oli-obk/patch-2
Update 0000-clippy-uno.md
@Manishearth

This comment has been minimized.

Show comment
Hide comment
@Manishearth

Manishearth Jun 14, 2018

Member

cc @rust-lang/dev-tools @rust-lang/compiler

This isn't tagged T-Compiler (maybe it should be?) but the uplift stuff does impact the compiler team.

Member

Manishearth commented Jun 14, 2018

cc @rust-lang/dev-tools @rust-lang/compiler

This isn't tagged T-Compiler (maybe it should be?) but the uplift stuff does impact the compiler team.

Show outdated Hide outdated text/0000-clippy-uno.md
Clippy aims to follow the general Rust style. It may be somewhat opiniated in some situations.
In general clippy is intended to be used with a liberal sprinkling of `#[allow()]` and `#[warn()]`; _it is okay_ to
disagree with Clippy's choices. This is a weaker philosophy than that behind rustc's lints, where usually flipping

This comment was marked as resolved.

@mcarton

mcarton Jun 14, 2018

Is it officially Clippy or clippy? I never new, and this RFC is not consistent either.

@mcarton

mcarton Jun 14, 2018

Is it officially Clippy or clippy? I never new, and this RFC is not consistent either.

This comment was marked as resolved.

@Manishearth

Manishearth Jun 14, 2018

Member

shrug we could establish this but I have no strong opinion

@Manishearth

Manishearth Jun 14, 2018

Member

shrug we could establish this but I have no strong opinion

This comment was marked as resolved.

@Centril

Centril Jun 15, 2018

Contributor

There's precedent for Clippy in Cargo; so the current wording seems consistent to me.

@Centril

Centril Jun 15, 2018

Contributor

There's precedent for Clippy in Cargo; so the current wording seems consistent to me.

This comment was marked as resolved.

@birkenfeld

birkenfeld Jun 15, 2018

Doesn't seem consistent yet - see line 34 and 35 :)

@birkenfeld

birkenfeld Jun 15, 2018

Doesn't seem consistent yet - see line 34 and 35 :)

This comment was marked as resolved.

@Manishearth

Manishearth Jun 15, 2018

Member

Changed to Clippy.

@Manishearth

Manishearth Jun 15, 2018

Member

Changed to Clippy.

# Rationale and alternatives
[alternatives]: #alternatives
We don't particularly _need_ a 1.0, however it's good to have a milestone here, and a general idea of stability as we move forward in this process.

This comment has been minimized.

@mcarton

mcarton Jun 14, 2018

I once gave a talk about clippy and the first question asked by the audience was "Why the fuck is your version 0.0.97? Are you ever going to increase from 0.0?". This was more than 100 versions ago.
We need to move away from 0.0 at some point.

@mcarton

mcarton Jun 14, 2018

I once gave a talk about clippy and the first question asked by the audience was "Why the fuck is your version 0.0.97? Are you ever going to increase from 0.0?". This was more than 100 versions ago.
We need to move away from 0.0 at some point.

This comment has been minimized.

@Victor-Savu

Victor-Savu Jun 22, 2018

Such an angry audience you had :) I hope they are not representative for the rust community.

@Victor-Savu

Victor-Savu Jun 22, 2018

Such an angry audience you had :) I hope they are not representative for the rust community.

This comment has been minimized.

@mcarton

mcarton Jun 23, 2018

They weren't particularly angry, just really astonished by such a weird version. I also mentioned semver in a previous talk about Rust at the same conference, and then here I am, presenting a tool that seems like it doesn't want to commit to a proper versioning. Kind of ironic for a tool that aims to help you with Rust good practises.

@mcarton

mcarton Jun 23, 2018

They weren't particularly angry, just really astonished by such a weird version. I also mentioned semver in a previous talk about Rust at the same conference, and then here I am, presenting a tool that seems like it doesn't want to commit to a proper versioning. Kind of ironic for a tool that aims to help you with Rust good practises.

Show outdated Hide outdated text/0000-clippy-uno.md
@Manishearth

This comment has been minimized.

Show comment
Hide comment
@Manishearth

Manishearth Jun 14, 2018

Member

cc the other clippy maintainers @llogiq @mcarton @phansch @flip1995 @birkenfeld

Member

Manishearth commented Jun 14, 2018

cc the other clippy maintainers @llogiq @mcarton @phansch @flip1995 @birkenfeld

@clarcharr

This comment has been minimized.

Show comment
Hide comment
@clarcharr

clarcharr Jun 14, 2018

Contributor

A few thoughts:

  1. How should clippy deal with stability of lints that recommend using an external crate? For example, the naive_bytecount lint will redirect the user to the bytecount crate. If this crate updates to a new major version (not likely in this case, but in general), how should the clippy lint respond?
  2. I recall somewhere there being a style guide for lint names for rustc, and I think that such a style should be adopted for clippy too. The names of the lints seem very inconsistent and all over the place, and it makes sense to standardise them before 1.0.
  3. There are a few lints that abbreviate words that I think should not. For example, cmp_owned might be better as owned_comparison rather than deferring to the cmp abbreviation used by Ord and PartialOrd. Similarly, manual_memcpy should be manual_slice_copy IMO because it talks about what's done, rather than deferring to the term memcpy which is again a function name.

Also:

  • unused_collect may be replaceable with a #[must_use] on collect? Not 100% sure but that seems to make sense to me.
Contributor

clarcharr commented Jun 14, 2018

A few thoughts:

  1. How should clippy deal with stability of lints that recommend using an external crate? For example, the naive_bytecount lint will redirect the user to the bytecount crate. If this crate updates to a new major version (not likely in this case, but in general), how should the clippy lint respond?
  2. I recall somewhere there being a style guide for lint names for rustc, and I think that such a style should be adopted for clippy too. The names of the lints seem very inconsistent and all over the place, and it makes sense to standardise them before 1.0.
  3. There are a few lints that abbreviate words that I think should not. For example, cmp_owned might be better as owned_comparison rather than deferring to the cmp abbreviation used by Ord and PartialOrd. Similarly, manual_memcpy should be manual_slice_copy IMO because it talks about what's done, rather than deferring to the term memcpy which is again a function name.

Also:

  • unused_collect may be replaceable with a #[must_use] on collect? Not 100% sure but that seems to make sense to me.
@Manishearth

This comment has been minimized.

Show comment
Hide comment
@Manishearth

Manishearth Jun 14, 2018

Member

If this crate updates to a new major version (not likely in this case, but in general), how should the clippy lint respond?

Still redirect them to the crate if the crate still works the same way. If not, remove the lint.

The names of the lints seem very inconsistent and all over the place, and it makes sense to standardise them before 1.0.
...
There are a few lints that abbreviate words that I think should not

Would you like to come up with a list of potential renames? 😄 It seems like you have a rough idea of a consistent system here. We can make this happen; and it doesn't need to happen in-band in this RFC (we can cross link a PR). It's in scope for this RFC but I want to break out discussions as much as possible.

Edit: Discussion at rust-lang-nursery/rust-clippy#2845

unused_collect may be replaceable with a #[must_use] on collect? Not 100% sure but that seems to make sense to me.

That's a fair point, could you open a rustc PR for that? We can deprecate the lint if it ends up landing. But that's out of scope for this RFC so I don't want to discuss it here too much 😄

Edit: Moved to rust-lang-nursery/rust-clippy#2846

Member

Manishearth commented Jun 14, 2018

If this crate updates to a new major version (not likely in this case, but in general), how should the clippy lint respond?

Still redirect them to the crate if the crate still works the same way. If not, remove the lint.

The names of the lints seem very inconsistent and all over the place, and it makes sense to standardise them before 1.0.
...
There are a few lints that abbreviate words that I think should not

Would you like to come up with a list of potential renames? 😄 It seems like you have a rough idea of a consistent system here. We can make this happen; and it doesn't need to happen in-band in this RFC (we can cross link a PR). It's in scope for this RFC but I want to break out discussions as much as possible.

Edit: Discussion at rust-lang-nursery/rust-clippy#2845

unused_collect may be replaceable with a #[must_use] on collect? Not 100% sure but that seems to make sense to me.

That's a fair point, could you open a rustc PR for that? We can deprecate the lint if it ends up landing. But that's out of scope for this RFC so I don't want to discuss it here too much 😄

Edit: Moved to rust-lang-nursery/rust-clippy#2846

@Diggsey

This comment was marked as resolved.

Show comment
Hide comment
@Diggsey

Diggsey Jun 15, 2018

Contributor

The lint categorisation section appears to have the same set of lints for all categories?

Contributor

Diggsey commented Jun 15, 2018

The lint categorisation section appears to have the same set of lints for all categories?

@F001

This comment was marked as resolved.

Show comment
Hide comment
@F001

F001 Jun 15, 2018

Contributor

I have a question that why it is named as "clippy". Why not just "rustlint" or something like that?

Contributor

F001 commented Jun 15, 2018

I have a question that why it is named as "clippy". Why not just "rustlint" or something like that?

@Centril

This comment has been minimized.

Show comment
Hide comment
@Centril

Centril Jun 15, 2018

Contributor

This RFC does not yet propose lints to be uplifted, but the intention is that the RFC discussion will bring up lints that the community feels should be uplifted and we can list them here.

Apologies in advance if this is a major land-grab, but since uplifting to rustc is being discussed here and that compiler lints are under the purview of the lang team, I'm also adding T-lang.

@F001

I have a question that why it is named as "clippy". Why not just "rustlint" or something like that?

In honour of Clippy, the Office Assistant. I think it is pretty cute.

Contributor

Centril commented Jun 15, 2018

This RFC does not yet propose lints to be uplifted, but the intention is that the RFC discussion will bring up lints that the community feels should be uplifted and we can list them here.

Apologies in advance if this is a major land-grab, but since uplifting to rustc is being discussed here and that compiler lints are under the purview of the lang team, I'm also adding T-lang.

@F001

I have a question that why it is named as "clippy". Why not just "rustlint" or something like that?

In honour of Clippy, the Office Assistant. I think it is pretty cute.

@Centril Centril added the T-lang label Jun 15, 2018

@Manishearth

This comment has been minimized.

Show comment
Hide comment
@Manishearth

Manishearth Jun 15, 2018

Member

I feel like lints fall under the purview of the compiler team; at least this discussion has been ongoing with the compiler team, not the lang team. (I didn't include the compiler team myself because I wanted them to make the decision of adding themselves)

Lints are a UI feature, not a language feature. Alternative implementations need not use the same set of lints.

Member

Manishearth commented Jun 15, 2018

I feel like lints fall under the purview of the compiler team; at least this discussion has been ongoing with the compiler team, not the lang team. (I didn't include the compiler team myself because I wanted them to make the decision of adding themselves)

Lints are a UI feature, not a language feature. Alternative implementations need not use the same set of lints.

@Manishearth

This comment has been minimized.

Show comment
Hide comment
@Manishearth

Manishearth Jun 15, 2018

Member

The lint categorisation section appears to have the same set of lints for all categories?

Cc @oli-obk bug in your script? :)

Member

Manishearth commented Jun 15, 2018

The lint categorisation section appears to have the same set of lints for all categories?

Cc @oli-obk bug in your script? :)

@Centril

This comment has been minimized.

Show comment
Hide comment
@Centril

Centril Jun 15, 2018

Contributor

@Manishearth Hmm well; It could be that the RFC policy - language design document is outdated, but just today we did discuss #2471 in the lang team meeting.

My rationale for continued T-lang purview (in addition to T-dev-tools) is mainly that while lints are a UI feature, as you say, compiler lints are important wrt. the feel of the language itself, so they factor into the design of the language. Of course, by that logic, major swaths of T-libs responsibilities (and of other teams..) could suddenly become T-lang, but you have to draw the line somewhere, so I draw the line at compiler lints.

Anyways, if the language team agrees this is not under their purview they can remove themselves... ;)
If that happens, we should update the lang_changes.md file in some way.

EDIT: nominating this for the next lang meeting so the question of purview itself can be dealt with quickly.

Contributor

Centril commented Jun 15, 2018

@Manishearth Hmm well; It could be that the RFC policy - language design document is outdated, but just today we did discuss #2471 in the lang team meeting.

My rationale for continued T-lang purview (in addition to T-dev-tools) is mainly that while lints are a UI feature, as you say, compiler lints are important wrt. the feel of the language itself, so they factor into the design of the language. Of course, by that logic, major swaths of T-libs responsibilities (and of other teams..) could suddenly become T-lang, but you have to draw the line somewhere, so I draw the line at compiler lints.

Anyways, if the language team agrees this is not under their purview they can remove themselves... ;)
If that happens, we should update the lang_changes.md file in some way.

EDIT: nominating this for the next lang meeting so the question of purview itself can be dealt with quickly.

@Centril Centril added the I-nominated label Jun 15, 2018

[online]: http://rust-lang-nursery.github.io/rust-clippy/current/
Please leave comments on thoughts about these lints -- if their categorization is correct, if they should exist at all, and if we should be uplifting them to the compiler.

This comment was marked as resolved.

@scottmcm

scottmcm Jun 15, 2018

Member

It looks like every single section in this RFC has the same lints? Copy-paste error?

@scottmcm

scottmcm Jun 15, 2018

Member

It looks like every single section in this RFC has the same lints? Copy-paste error?

This comment was marked as outdated.

@birkenfeld

birkenfeld Jun 15, 2018

And there was I commenting that all those lints belong to perf...

@birkenfeld

birkenfeld Jun 15, 2018

And there was I commenting that all those lints belong to perf...

@Manishearth

This comment has been minimized.

Show comment
Hide comment
@Manishearth

Manishearth Jun 15, 2018

Member

I think some lints are lang team things, but not in general. I consider that document outdated because Rust has had a semi official "no new lints" policy for ages which effectively means it never got exercised, and historically we've added lints along with language changes to support them, or without an RFC at all in case of things like soundness deprecations.

Compiler lints are as important as diagnostics in the feel of the language imo, but diagnostics are squarely a compiler team concern. Docs are also in a similar space here. Ultimately everything we do here impacts Rust the language 😄


I basically want to avoid this becoming a three team RFC 😄

And also, this is something we've been discussing with the compiler team for a while which is why I want to avoid additional churn and rehashing things we've discussed.

Member

Manishearth commented Jun 15, 2018

I think some lints are lang team things, but not in general. I consider that document outdated because Rust has had a semi official "no new lints" policy for ages which effectively means it never got exercised, and historically we've added lints along with language changes to support them, or without an RFC at all in case of things like soundness deprecations.

Compiler lints are as important as diagnostics in the feel of the language imo, but diagnostics are squarely a compiler team concern. Docs are also in a similar space here. Ultimately everything we do here impacts Rust the language 😄


I basically want to avoid this becoming a three team RFC 😄

And also, this is something we've been discussing with the compiler team for a while which is why I want to avoid additional churn and rehashing things we've discussed.

@joshtriplett

This comment has been minimized.

Show comment
Hide comment
@joshtriplett

joshtriplett Sep 2, 2018

Member

@dwijnand Including Cargo, it seems: https://github.com/rust-lang/cargo/blob/master/src/cargo/lib.rs

I feel a little less strongly about explicit_into_iter_loop, but I'd certainly not complain if it ended up switched to "Allow" as well.

Member

joshtriplett commented Sep 2, 2018

@dwijnand Including Cargo, it seems: https://github.com/rust-lang/cargo/blob/master/src/cargo/lib.rs

I feel a little less strongly about explicit_into_iter_loop, but I'd certainly not complain if it ended up switched to "Allow" as well.

@joshtriplett

This comment has been minimized.

Show comment
Hide comment
@joshtriplett

joshtriplett Sep 3, 2018

Member

@Manishearth Pull request, to go along with the requested lint reclassification: rust-lang-nursery/rust-clippy#3119 😁

Member

joshtriplett commented Sep 3, 2018

@Manishearth Pull request, to go along with the requested lint reclassification: rust-lang-nursery/rust-clippy#3119 😁

@Manishearth

This comment has been minimized.

Show comment
Hide comment
@Manishearth

Manishearth Sep 3, 2018

Member

It merged and there seemed to be general ageement

@rfcbot resolve explicit-iter-loop-level

Member

Manishearth commented Sep 3, 2018

It merged and there seemed to be general ageement

@rfcbot resolve explicit-iter-loop-level

@phansch

This comment has been minimized.

Show comment
Hide comment
@phansch

phansch Sep 5, 2018

AFAICT one open question is regarding the clippy.toml.

I think what @oli-obk said can be a good solution.
We could require a new config to be set that's called clippy_toml_is_unstable_and_may_go_away.
If it is not set, it will show a warning when Clippy is executed.
Once the config is included, the warning will go away.

How would this work with the RLS <-> Clippy integration, though?

phansch commented Sep 5, 2018

AFAICT one open question is regarding the clippy.toml.

I think what @oli-obk said can be a good solution.
We could require a new config to be set that's called clippy_toml_is_unstable_and_may_go_away.
If it is not set, it will show a warning when Clippy is executed.
Once the config is included, the warning will go away.

How would this work with the RLS <-> Clippy integration, though?

@Manishearth

This comment has been minimized.

Show comment
Hide comment
@Manishearth

Manishearth Sep 5, 2018

Member

@rfcbot concern clippy-toml-stability

Should we be stabilizing it? Or declare it unstable for now a la #2476 (comment) ?

Member

Manishearth commented Sep 5, 2018

@rfcbot concern clippy-toml-stability

Should we be stabilizing it? Or declare it unstable for now a la #2476 (comment) ?

@Manishearth

This comment has been minimized.

Show comment
Hide comment
@Manishearth

Manishearth Oct 9, 2018

Member

@rfcbot resolve clippy-toml-stability

discussed a bit in the meeting, clippy.toml is explicitly unstable

Member

Manishearth commented Oct 9, 2018

@rfcbot resolve clippy-toml-stability

discussed a bit in the meeting, clippy.toml is explicitly unstable

@fitzgen

This comment has been minimized.

Show comment
Hide comment
@fitzgen

fitzgen Oct 9, 2018

Member

@rfcbot reviewed

Member

fitzgen commented Oct 9, 2018

@rfcbot reviewed

@rfcbot

This comment has been minimized.

Show comment
Hide comment
@rfcbot

rfcbot Oct 9, 2018

🔔 This is now entering its final comment period, as per the review above. 🔔

rfcbot commented Oct 9, 2018

🔔 This is now entering its final comment period, as per the review above. 🔔

@withoutboats

This comment has been minimized.

Show comment
Hide comment
@withoutboats

withoutboats Oct 9, 2018

Contributor

@rfcbot concern cargo-clippy

Following from the discussion of rust-lang-nursery/rust-clippy#1358, I'm not certain that cargo clippy is the interface we want to settle around for accessing this set of lints. Other than a few references at the beginning of the RFC, I notice that the interface of the cargo clippy subcommand is essentially not discussed in this RFC.

I think the most expedient thing would be to edit the RFC to avoid asserting that the interface to clippy will be a cargo clippy command, and to just say that we intend to ship clippy with rustup, providing the lints described in the RFC, expanding further to new lints along the guidelines established in the RFC.


I'm also concerned that the rules for uplifting lints into rustc are too vague, but I think we're managing that discussion well enough on rust-lang/rust#53224 and don't think I need to register a concern here regarding that.

Contributor

withoutboats commented Oct 9, 2018

@rfcbot concern cargo-clippy

Following from the discussion of rust-lang-nursery/rust-clippy#1358, I'm not certain that cargo clippy is the interface we want to settle around for accessing this set of lints. Other than a few references at the beginning of the RFC, I notice that the interface of the cargo clippy subcommand is essentially not discussed in this RFC.

I think the most expedient thing would be to edit the RFC to avoid asserting that the interface to clippy will be a cargo clippy command, and to just say that we intend to ship clippy with rustup, providing the lints described in the RFC, expanding further to new lints along the guidelines established in the RFC.


I'm also concerned that the rules for uplifting lints into rustc are too vague, but I think we're managing that discussion well enough on rust-lang/rust#53224 and don't think I need to register a concern here regarding that.

@Manishearth

This comment has been minimized.

Show comment
Hide comment
@Manishearth

Manishearth Oct 9, 2018

Member

rules for uplifting lints into rustc are too vague

This is intentional, we don't want to legislate too strongly what gets uplifted, more of give some guidelines and mention that uplifts should happen. Actual uplifts should be discussed case by case, as they are in rust-lang/rust#53224


Regarding cargo clippy, I personally like having cargo clippy but having clippy Just Work in Rust (via a lint key in cargo.toml, or just cargo lint) would be pretty neat, too.

Amended RFC to punt on cargo-clippy till later.

Member

Manishearth commented Oct 9, 2018

rules for uplifting lints into rustc are too vague

This is intentional, we don't want to legislate too strongly what gets uplifted, more of give some guidelines and mention that uplifts should happen. Actual uplifts should be discussed case by case, as they are in rust-lang/rust#53224


Regarding cargo clippy, I personally like having cargo clippy but having clippy Just Work in Rust (via a lint key in cargo.toml, or just cargo lint) would be pretty neat, too.

Amended RFC to punt on cargo-clippy till later.

@withoutboats

This comment has been minimized.

Show comment
Hide comment
@withoutboats

withoutboats Oct 10, 2018

Contributor

@rfcbot resolve cargo-clippy

I think we have a shared understanding of what we still don't have consensus on.

This is intentional, we don't want to legislate too strongly what gets uplifted, more of give some guidelines and mention that uplifts should happen. Actual uplifts should be discussed case by case, as they are in rust-lang/rust#53224

I've raised a concern about that on the issue linked, which we should continue discussing there.

Contributor

withoutboats commented Oct 10, 2018

@rfcbot resolve cargo-clippy

I think we have a shared understanding of what we still don't have consensus on.

This is intentional, we don't want to legislate too strongly what gets uplifted, more of give some guidelines and mention that uplifts should happen. Actual uplifts should be discussed case by case, as they are in rust-lang/rust#53224

I've raised a concern about that on the issue linked, which we should continue discussing there.

@rfcbot

This comment has been minimized.

Show comment
Hide comment
@rfcbot

rfcbot Oct 10, 2018

🔔 This is now entering its final comment period, as per the review above. 🔔

rfcbot commented Oct 10, 2018

🔔 This is now entering its final comment period, as per the review above. 🔔

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment