rust-lang
Suggest `#[expect(...)]` instead of `#[allow(...)]` to ensure relevance
What it does
With the introduction of #[expect] in 1.81.0, it is now possible to ensure that lint is actually relevant - i.e. there is no "allow" that does not get used. This lint would offer to replace all allow with expect
Advantage
- keep lint declarations relevant to the actual code
- avoids useless lint declarations, keeping the code tidy
Drawbacks
No idea who would want to "allow" just in case...
Example
#![allow(some_lint)]
Could be written as:
#![expect(some_lint)]
oh, i was searching for it in the clippy issues, but only looked at the open ones. Thx! One question - why not also enable it for the inner ones? I would love to ensure by global lints are still relevant. The only exception would be the ones in Cargo.toml because there a lint could be shared across multiple crates.
No idea who would want to "allow" just in case...
There may be several possible reasons, e.g.
Thus prefer ``expect`` over ``allow`` unless:
- Conditional compilation triggers the warning in some cases but not others.
If there are only a few cases where the warning triggers (or does not
trigger) compared to the total number of cases, then one may consider using
a conditional ``expect`` (i.e. ``cfg_attr(..., expect(...))``). Otherwise,
it is likely simpler to just use ``allow``.
- Inside macros, when the different invocations may create expanded code that
triggers the warning in some cases but not in others.
- When code may trigger a warning for some architectures but not others, such
as an ``as`` cast to a C FFI type.
from https://docs.kernel.org/next/rust/coding-guidelines.html#lints.
The docs of allow_attributes could perhaps mention some of that.
I guess this can be closed as already done with the clippy::allow_attributes