Reading through the documentation on lints, it seems like really isn't an opening for lints defined by the implementation that are accepted by other implementations (even if they do not support such lints). As someone working on an alternative implementation of rust, I would like to propose such a mechanism, for implementations to define lints beyond those which are a part of the core language. This mechanism is "implementation-defined" lints, which extends tool lints
A lint name of the form
IDENTIFIER::SimplePath is an implementation-defined lint. An implementation shall accept any lint of this form, and issue no diagnostic for an unrecongized lint in this form, except that it may issue an implementation-defined warn-by-default lint if an unrecognized lint name occurs within the tool-name chosen below. The lints of this form that are recognized and their meanings are implementation-defined. An implementation should choose a tool-name that all lints recognized by it are defined within, and may accept variants on that namespace with the same meaning (for example, if an implementation accepts implementation-defined lints with the
foo namespace, it could also accept
This (Pre-)RFC recommends the use of the
rustc namespace by the rustc compiler. Whether or not it accepts variants of this namespace is not specified. All existing lints for rustc should be categorized as core language and implementation-defined, and the latter should be renamed to this form and have it's original form deprecated. This (Pre-)RFC does not provide any recommendations for how existing lints are categorized. A future RFC is recommended to define this split, and the former category shall become mandatory for implementations to be implemented. Implementations should accept, and may issue a lint, for attributes in the second category.
For compatibility with existing tool lints, the
clippy namespace is reserved for use with the tool
clippy, and continues to operate as specified in RFC 2103 and RFC 2476 as well as any others I have not mentioned to this effect. Future tools that make use of tool lints should use the mechanism prescribed here.
Open Question: This Pre-RFC only seeks to extend lints, but it may be useful similarily extend attributes. One note is that attributes may have effects beyond changing a lint level, and the policy for lint level changes is that lints are minor changes. It is possible that use of (undefined) attributes of this form may be sufficient to "opt-in" to breaking changes from future compiler versions and use in alternative implementations.