Skip to content
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

Create more than 2 lint groups #743

Closed
mcarton opened this issue Mar 6, 2016 · 11 comments
Closed

Create more than 2 lint groups #743

mcarton opened this issue Mar 6, 2016 · 11 comments
Labels
A-category Area: Categorization of lints C-enhancement Category: Enhancement of lints, like adding more cases or adding help messages S-needs-discussion Status: Needs further discussion before merging or work can be started

Comments

@mcarton
Copy link
Member

mcarton commented Mar 6, 2016

Currently we have two lint groups, clippy and clippy_pendantic.

We’ve already discussed that we should have more.

I can think of:

  • clippy_deprecated: group where we move lints we ultimately want to remove (ref as_slice will be stable in 1.7 #728);
  • clippy_non_api_breaking: subgroup of clippy with only lints whose fix would not change the public API (eg. no ptr_arg, type_complexity, wrong_pub_self_convention, etc.). Useful for crate which did not use Clippy historically and don’t want to change their API. Or maybe clippy_api_breaking with only those lints? Or both and ensure any lint is in either one?

Can you think of other groups you’d want?

@mcarton mcarton added C-enhancement Category: Enhancement of lints, like adding more cases or adding help messages S-needs-discussion Status: Needs further discussion before merging or work can be started labels Mar 6, 2016
@llogiq
Copy link
Contributor

llogiq commented Mar 6, 2016

Perhaps subgroups of clippy based on goals, like clippy_style, clippy_performance, clippy_badcode or something similar? On the other hand, there's probably not much value in having them besides documentation.

@mcarton
Copy link
Member Author

mcarton commented Mar 6, 2016

Yep. While documentation is a good thing, I don’t know if that should be reflected in a lint group.

@Manishearth
Copy link
Member

I don't think overlapping or nested groups work well.

Mostly; I was thinking of keeping pedantic, and adding three more. clippy_stable which suggests stable ways to do unstable things, clipy_restrictions for containing things which aren't style choices (see Graydon's issue), and clippy_deprecated for the deprecated ones.

I'd like to keep the Warn lints in clippy as much as possible.

@llogiq
Copy link
Contributor

llogiq commented Mar 7, 2016

So cyclomatic_complexity would be our first restrictions lint, right?

@Manishearth
Copy link
Member

idk. I think cyclomatic complexity with a sensible limit is a valid style lint.

@oli-obk
Copy link
Contributor

oli-obk commented Mar 7, 2016

restrictions are something like deny(allocations) or deny(unsafe) (actually when using restrictions one should use forbid). I'm not sure that a lint-group makes sense for restrictions, because it's unlikely you'll ever want to activate all of them.

@Manishearth
Copy link
Member

Right, but I don't want any lints in clippy to be groupless.

@llogiq
Copy link
Contributor

llogiq commented Mar 12, 2016

Perhaps we could also add a "newbie" lint group. IMHO inline_always and linked_list would happen to fall in that category. Those are lints that offer reasonable advice to newbies that experts will sometimes find good reason to act against.

@Manishearth
Copy link
Member

I think almost all our lints have cases where experts will have good reason to act against. IMO newbie lints should be part of the regular stuff.

(note that inline_always's issues aren't common knowledge)

@clarfonthey
Copy link
Contributor

FWIW I think that clippy_incorrect and clippy_idiomatic might be useful. The former lints things that are probably bugs, and the latter suggests rewording things to a more "rusty" way. Someone might not care about the latter, but still the former.

@camsteffen camsteffen added the A-category Area: Categorization of lints label Feb 23, 2021
@camsteffen
Copy link
Contributor

Closing since there are newer issues and a lot has changed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-category Area: Categorization of lints C-enhancement Category: Enhancement of lints, like adding more cases or adding help messages S-needs-discussion Status: Needs further discussion before merging or work can be started
Projects
None yet
Development

No branches or pull requests

7 participants
@oli-obk @Manishearth @mcarton @llogiq @camsteffen @clarfonthey and others