Lints could have error codes

[huonw]

Lint messages don't always explain the error in much detail, and so would often benefit from a detailed --explain explanation just like normal errors, e.g. this will hit a dead_code warning, but that doesn't really help diagnose the problem (that mod foo; is private), a detailed explanation could include discussion of the privacy/modules aspect of the lint.

#![crate_type = "lib"]
mod foo;

// foo.rs
pub fn bar() {}

foo.rs:2:1: 2:12 warning: function is never used: `bar`, #[warn(dead_code)] on by default
foo.rs:2 fn bar() {}
         ^~~~~~~~~~~

It might also make sense to have a generic "lints" detailed explanation, that (a) lints that don't have their own error message point to, and (b) that any specific lint explanation also points to ("see also [E...] for more on lints"). This could include the common details of how the allow/etc. attributes work.

On the other hand, lints may change too fast for this to make sense.

cc @michaelsproul #24407

[michaelsproul]

I like it. We could even namespace lints differently, like L0001.

[huonw]

Interesting.

Namespacing has the downside of exposing implementation details that may not hold true in future, e.g. if a lint moves around/uses some different infrastructure it may no longer make sense to be classed as L..., but changing numbers isn't really possible. However, it seems likely to me that there is a hard distinction between lints and compiler errors that will always be true: the former has levels (including 'disabled').

[caspark]

I want to emphasize that the most useful portion of such lints would be an explanation of how to turn them off or suppress them, both globally or in the specific case.

As such, perhaps it would make sense to have a generic reusable explanation of #[blah] vs #![blah] (perhaps as L0000).

For the extended message for the dead_code case specifically, it might also make sense to have a pointer to cfg, cfg_attr and the associated possible logic options, as those things (particularly cfg_attr and the logic options) are not easy to stumble upon in my experience - even if that's only a pointer to the relevant section of the official docs. I only found out about cfg_attr when Huon mentioned it to me (context: wrote about 2-3,000 lines of Rust over the last 3-4 months before that).

[llogiq]

How would this work with external lints? Should they have their own namespace? What happens if two plugins accidentially use the same error codes? Do we need a central registry?

"What could go wrong?" — famous last quotes...

[steveklabnik]

Triage: no change

[estebank]

Lints now have DiagnosticIds: #45484.