Wherein we look at clippy, which has recently reached a pretty arbitrary milestone.
3 Likes
I think a small number of those lints should be moved in the Rustc compiler.
1 Like
I'm not sure about that. This would put the onus of maintaining the lints on the rustc team, which isn't exactly keen on taking on more work (a rationale I sympathize with). Let's wait until the plugin API stabilizes a bit, then we'll see.
Nice. It would be very cool if the name of each lint linked to a description of what the lint does and also the copy-and-pastable text to use to turn that particular lint on or off.
In languages like C most people doesn't use lints, so you must push as many lints as possible inside the compiler.
If Clippy becomes a tool every Rust programmer worth some respect will use all the time, then we can remove all Rustc warnings and move them into Clippy.
But I think a better solution is similar to the current one: the lints that are near-errors should be in the compiler, and all other lints should be in external tool. In my opinion this means adding about 3 or 4 Clippy lints (that correspond to hard errors in the D compiler) to Rustc.
(Extra note: I've asked for years for D warnings to be active by default in the D compiler, but nothing has ever changed. So I was quite happy to see that the Rustc compiler has taken the right design choice).
I added links to the rust-clippy wiki which contains a description for each lint. The README has info on how to change lint settings.