Unify non-snake-case lints and non-uppercase statics lints; add lint groups

[ftxqxd]

This unifies the non_snake_case_functions and uppercase_variables lints into one lint, non_snake_case. It also now checks for non-snake-case modules. This also extends the non-camel-case types lint to check type parameters, and merges the non_uppercase_pattern_statics lint into the non_uppercase_statics lint.

Because the uppercase_variables lint is now part of the non_snake_case lint, all non-snake-case variables that start with lowercase characters (such as fooBar) will now trigger the non_snake_case lint.

New code should be updated to use the new non_snake_case lint instead of the previous non_snake_case_functions and uppercase_variables lints. All use of the non_uppercase_pattern_statics should be replaced with the non_uppercase_statics lint. Any code that previously contained non-snake-case module or variable names should be updated to use snake case names or disable the non_snake_case lint. Any code with non-camel-case type parameters should be changed to use camel case or disable the non_camel_case_types lint.

This also adds support for lint groups to the compiler. Lint groups are a way of grouping a number of lints together under one name. For example, this also defines a default lint for naming conventions, named bad_style. Writing #[allow(bad_style)] is equivalent to writing #[allow(non_camel_case_types, non_snake_case, non_uppercase_statics)]. These lint groups can also be defined as a compiler plugin using the new Registry::register_lint_group method.

This also adds two built-in lint groups, bad_style and unused. The contents of these groups can be seen by running rustc -W help.

[breaking-change]

[alexcrichton]

I'm a little uneasy about the continued proliferation of micro-lints, especially for various style criteria. I think I would rather push lints like these all under the same "non snake case" lint rather than a "non snake case X" lint.

[ftxqxd]

I agree—the level of control over style lints right now is far too fine-grained. Do you think it would be a good idea to unify some other lints (like non_uppercase_pattern_statics into non_uppercase_patterns, uppercase_variables into non_snake_case) in the process?

(It should be noted that right now uppercase_variables only checks the first character of variable names, while merging it into non_snake_case would make it check the entire string. It is possible that quite a lot of existing code has non-snake-case variables that aren’t being checked by the current lint.)

[ftxqxd]

OK, I’ve merged the uppercase and snake case lints together. I’m not sure if this counts as a breaking change or not.

[alexcrichton]

Thanks @P1start! I do think that this needs a [breaking-change] annotation because some lints are removed which may cause compilation failure downstream.

cc @brson, @aturon, I like the direction this is going, I'm not sure if we want to go all the way towards just one allow(style) lint or not or keep the separation as is.

[huonw]

I like the direction this is going, I'm not sure if we want to go all the way towards just one allow(style) lint or not or keep the separation as is.

Maybe we could have umbrella lints? So one still have fine-grained control of individual things, but the 'common' cases are covered by lints like #[allow(style)].

[ftxqxd]

@huonw Maybe that could be done with a normal attribute that expands to a number of lint attributes? So something like #[disable_style_checks] could expand to #[allow(non_snake_case)] #[allow(non_camel_case_types)] #[allow(non_uppercase_statics)] (if that’s actually possible).

[huonw]

I don't like it; it's a whole new attribute to remember and use, and isn't very extensible, e.g. what if one wants #[deny(style)] to enforce the style guide, or what if we want an umbrella lint like #[deny(unused)] that collects unused_variable, unused_mutability and dead_code?

[ftxqxd]

Perhaps the most flexible solution would be to allow lints to have parameters. All the style lints could be put into one lint, with parameters for fine-tuning. So #[deny(style(non_uppercase_statics = warn))] would deny all bad style, except only warn on non-uppercase statics. All the existing style lints would be removed. (@huonw, your spellck plugin would also presumably benefit from this.)

[alexcrichton]

Yes @huonw I think that may be a good direction to start going in. Messaging that in terms of error messages may get tricky, but I think it may be good to have.

[ftxqxd]

Should I add umbrella lints (#[allow(bad_style)]) to this PR, or put that in another PR? I’m beginning to get them working, so I might as well bunch them together with the current changes in this PR.

[ftxqxd]

Well, I’ve added lint groups/umbrella lints. I’ve also added two built-in lint groups named bad_style and unused. The name for bad_style is not very good, but I couldn’t think of anything better. (Something like #[forbid(names_that_go_against_the_naming_conventions)] would be perfect if not for the obvious flaw that it is too long.)

[alexcrichton]

@P1start this looks pretty good to me, I'd like to gain a few more opinions about umbrella lints, however, because this is a pretty big feature for the compiler.

[aturon]

My 2c: I think umbrella lints are a very useful idea, and I don't see a lot of downside. So +1 from me!

[nikomatsakis]

Not quite +1: see http://discuss.rust-lang.org/t/umbrella-lints/307 (TLDR -- I am concerned about backwards compat)

[alexcrichton]

This was discussed in yesterday's meeting and we decided to merge it, thanks for being patient @P1start!

[ftxqxd]

Updated; tests pass locally. I should probably also note that this change makes make spit out thousands of lines of warnings. (This would be fixed with a snapshot.)

[alexcrichton]

Argh sorry @P1start, this totally fell under the radar! Feel free to ping PRs if they don't seem to have much activity to spur us into action!

[ftxqxd]

Updated again; tests pass locally.