When lints are triggered, people often add an allow instead of fixing them. But later, the lint may go away for some reason - maybe it was a false positive and the bug was fixed, or maybe the dev actually fixed the problem and forgot to remove the allow.
It would be really nice if allows would warn if they are for lints which wouldn't trigger anyway.
Is this something that would be okay for me to contribute?
This adds the #[expect(...)] attribute for this usecase. That allows distinguishing between situations where you're temporarily expecting a lint to fire and want to remove it if it stops being an issue, and situations where you're just saying "this lint doesn't make sense here" whether or not it's currently failing. (There's a little discussion in the RFC thread linked from that tracking issue on why to create a new lint level for it rather than changing the meaning of allow).
For example, I may allow a lint which only triggers for some targets, depending on complex cfg within the code, and I don't wish to duplicate that logic on the allow itself.
Sometimes when I'm writing macros I find myself needing to put an allow that may-or-may-not be needed, depending on the specific macro invocation. A feature like this would have to account for that (perhaps most simply, by not warning for any needless allow that is in a macro)
Another case I can think of is if some versions of the compiler/clippy diagnose something but not others (either because there’s been an improvement in detection, or because there’s been a regression). That could be solved with extra annotations, or additional conditions cfg_attr-style, but today a plain allow can take care of that. Though that’s also the very pattern that leads to allows sticking around forever, so…