Lint warning names should be more consistent

[rusty-nail]

I noticed some inconsistencies in the naming of compiler warnings. For example, compare:

#[allow(unused_variable)]
#[allow(unused_imports)]
#[allow(unused_attribute)]
#[allow(non_snake_case_functions)]
#[allow(uppercase_variables)]

This jumps back and forth between singular and plural. uppercase also feels a bit inconsistent with snake_case and camel_case, but it's less clear-cut. Maybe non_snakecase_functions would make the grouping more obvious than non_snake_case_functions, to avoid the parse error "non-snake case-functions".

Perhaps part of the reason for the inconsistency is that the warning names are scattered across lint/builtin.rs, which doesn't make it easy for contributors to have a global view in mind.

[steveklabnik]

/cc @aturon

[aturon]

Nominating for 1.0, P-backcompat-lang. We do not have stability attributes on lints, and so when we hit 1.0 the names of these lints are effectively locked down.

This should be easy to resolve by writing up a short conventions RFC and then implementing it. Needs to happen soon, though.

[aturon]

(This might be P-backcompat-libs instead, depending on how you categorize lints.)

[pnkfelix]

Assigning P-backcompat-lang, 1.0.

[pcwalton]

@aturon Any progress on this?

[aturon]

@pcwalton This was included in a broad conventions RFC that I intend to bring to the weekly meeting next week.

I will have a PR resolving this issue ready to merge as soon as the RFC is accepted.