You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
we add #[allow(lint)] to a function to suppress a lint, when that function's body changes and no longer raises that lint, we have the old #[allow(lint)] annotation silently staying there
we might also add #[allow(lint)] to a function because we're sure it will raise that lint, and we turn out to be wrong we dont realize we added that for no reason
Lint Name
unused_allow
Category
style
Advantage
keeps code clean
doesnt give the idea that the function raises the lint
gives no hint to the history of a function
Drawbacks
we might wanna allow a lint to express that we dont care if this happens in the future, in which case we can also allow this lint to express that more explicitly
Hey @laralove143, this is a feature which would need to be implemented in the compiler and not Clippy. There was already an RFC to add a feature like this, see: rust-lang/rfcs#2383. If you're interested, you can ready the tracking issue and the linked Zulip conversation. The stabilization is currently held up on a discussion how the new attribute should exactly work. If you have any thoughts on the matter or additional use cases, I'd highly appreciate your input :)
I'm closing this issue, as the discussion moved into the tracking issue. If such a lint would be added, it would need to be implemented in rustc anyways :)
What it does
we add
#[allow(lint)]
to a function to suppress a lint, when that function's body changes and no longer raises that lint, we have the old#[allow(lint)]
annotation silently staying therewe might also add
#[allow(lint)]
to a function because we're sure it will raise that lint, and we turn out to be wrong we dont realize we added that for no reasonLint Name
unused_allow
Category
style
Advantage
Drawbacks
we might wanna allow a lint to express that we dont care if this happens in the future, in which case we can also allow this lint to express that more explicitly
Example
say we think ignoring an error is fine
then we realize we do need to handle the error so we rewrite the function to
but here
#[allow(unused_must_use)]
stays even tho it doesnt need toThe text was updated successfully, but these errors were encountered: