I think a small number of those lints should be moved in the Rustc compiler.
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).