I just want to say that I am strongly in favor of this idea. Some lints/warnings should not come from clippy
but from rustc
itself. For instance:
-
the
unimplemented!
macro should trigger a warning. If, like @dtolnay, you think it will clutter the compilation with too many warnings, then you could just add a#![allow(unimplemented)]
. Saying thatunimplemented!
is easy to grep is like saying that there was no need for-Wformat-security
in C since erroneous usage of format strings can be spoted using$ grep -RnE '\bv?(sn?)?printf *\( *[^"]' .
(ok, that’s a strawman “argument”, I agree that those two things are not really comparable and apologise for that; but still, the “no need for a warning thanks to grep” looks like a weird argument to me); -
regarding the whole "spotting dependencies that use
unsafe
" topic, warning on unsafe could be a nice opt-in lint (a special kind of lint, that could transitively override the enabled state on the specified dependencies)
But, between the time (some) people feel the need to have some kind of warning and when it is finally included in the language (if ever), custom warnings would come in handy.
For reference, a dirty hack to get the “custom warning message” working today (I use it with my override of unimplemented!
so that it triggers a warning), is to use the #[must_use = $error_msg]
on a custom type (or a custom function):
Crate ::compile_warning
:
#[macro_export]
macro_rules! compile_warning {(
$name:ident, $message:expr $(,)*
) => (
mod $name {
#[must_use = $message]
struct compile_warning;
#[allow(dead_code)]
fn trigger_warning () { compile_warning; }
}
)}
Main crate:
#[macro_use] extern crate compile_warning;
fn main() {
compile_warning!(example, "Memento buggy");
}
$ cargo check
warning: unused `main::example::compile_warning` that must be used
--> src/main.rs:4:5
|
4 | compile_warning!(example, "Memento buggy");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: #[warn(unused_must_use)] on by default
= note: Memento buggy
= note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)
This is quite hacky and dirty (cannot use the same “warning name” within a given namespace twice + it uses the unused_must_use
“lint space”), and could be greatly improved by what the OP suggests.
That being said, most points raised by @dtolnay remain valid : there is still work to make an actual RFC out of this idea.