Take stock of and evaluate the lint situation.

[nrc]

We currently have a bunch of lints in the compiler (listed here: librustc/lint/builtin.rs) and a lot more in Clippy. Which lints exist and where they exist is pretty much historical accident - in the past we added lints to the compiler, more recently we've tried to avoid adding them to the compiler and instead added them to Clippy. Clippy in turn has (AIUI) two ranks of lints - normal and pedantic.

We don't have much of a vision for how lints fit into the Rust universe, and we should (where they should live, how many there should be, how they should work, how they can be customised, some kind of stability story). Furthermore, we should rationalise the current situation.

cc @rust-lang/tools, @Manishearth, @llogiq

[ticki]

I am all for moving some of the clippy lints into rustc itself. Some of these fits better in the compiler itself, than a seperate plugin.

[Manishearth]

Clippy in turn has (AIUI) two ranks of lints - normal and pedantic.

FWIW in the future clippy may have more. Normal lints will be Warn, and Allow lints will be classified in three or more groups:

• pedantic: lints which are not a clear style choice (i.e. half the Rust community may prefer the style the lint eschews), or contain too many false positives.
• stability: lints which suggest alternate APIs when using unstable features
• "restrictions": lints which let you enforce a needs-based restriction, i.e. "no floating points" or "no panics" (see https://github.com/Manishearth/rust-clippy/issues/632)

We don't have much of a vision for how lints fit into the Rust universe

I think at the very least if we're not going to be expanding the number of lints in clippy, we should make it easy to cargo install clippy (currently not possible since clippy isn't a binary and can't be made into one without becoming a lot more unstable; see rust-lang/cargo#2386)

where they should live

I personally don't have any strong opinion here. As far as vision is concerned I am very much for more static checks, and think that Rust as a community should also lean that way (AFAICT it does already) -- if it can be checked at compile time, it should be. Beyond that, I don't care where the static checks live; they could be in clippy or rustc or both. I do feel that we should try uplifting lints from clippy to rustc more often (ones which have zero false positives and are consistently liked), though.

how they can be customised

For customization, clippy eventually wants to get a clippy.toml or something that lets you configure lint defaults at a per-project or per-user level. Unsure about rustc.

some kind of stability story

Lints which are Deny by default should be stable, but otherwise IMO Warn lints should be allowed to evolve. A plugin API to handle lint renames would be nice (so that one can register the old name as an alias).

Clippy hasn't gone 1.0 yet because I plan to RfC the defaults once before that, but afterwards the above was how I roughly planned to think about stability.

how many there should be

Infinity?

[oli-obk]

some kind of stability story

Since the compiler-internals (HIR) will never be stable as far as I understand, but there will be some kind of interface to rustc for IDEs (I'm guessing that these will be stable at some point), we can port the lints to the IDE-interface once that time comes.

AST-lints can be stabilized either through something like syntex or when the AST becomes stable.

we should rationalise the current situation.

The ability to create static analysis without much effort is imo a major plus for Rust. We should not be fixing bugs, we should be fixing classes of bugs. Whenever I have an itch b/c of something that can easily be detected, I end up writing a lint to detect it for me.

[Centril]

Closing in favor of rust-lang/rust#53224.