-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to allow clippy::similar_names #9514
Comments
I think there's just confusion in what the semantics of this lint does. I think you're expecting to be "Exclude this name from the list of names that are checked for similar variable names", but the lint itself is closer to the semantics of "Make sure nothing is similar in the applied scope", which does nothing in your examples since |
That's certainly possible! I don't know how to tell what the intent is. In showing this issue to several other people, no one thought what I was trying to do was unreasonable. If it's the case that we don't want the lint to work the way I was expecting, it would be helpful to make this more obvious. Maybe the solution is just an update to the lint docs to make this clear. I suppose the current behavior is reasonable, although it does allow some cases to slip through. For example if there's a single block with one set of similar names you want to ignore, but you want to be warned about any other similar names. Seems pretty unlikely though which is why I think it's reasonable (as long as the expectation is clear). |
Add note to clippy::non_expressive_names doc Addresses confusion in rust-lang/rust-clippy#9514 by updating the lint docs.
Addressed the confusion with rust-lang/rust#102123 |
I'd say we can still fix this to not fire a lint if there's an allow on the relevant binding |
Add note to clippy::non_expressive_names doc Addresses confusion in rust-lang#9514 by updating the lint docs.
I am unable to disable (allow) the
clippy::similar_names
lint the way I expect. Usually I would place#[allow(clippy::x)]
before the offending line, and the lint error would go away. In this case the allow seems to have no effect.For example, this code shows the lint error being given despite being allowed on the
testb
line (playground):I expected that allowing on the
testb
line would hide the error since that's the line referenced by the error message. To cover my bases, I can also put the allow ontesta
with the same result (playground):What does work is allowing on the containing function (playground). But of course this prevents other instances from being caught so is not an ideal workaround.
I found this on stable 1.63 but also seems to occur on beta and nightly.
The text was updated successfully, but these errors were encountered: