-
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
Consider disabling eq_op
in test code
#7080
Comments
I agree the example is obviously a test for #[test]
fn test() {
let x = some_fn();
let y = x.some_transformation();
assert_eq!(x.field1, y.field1);
assert_eq!(x.field2, x.field2); // oops
} It could be restricted to tests which only have a single variable. |
Yes, that is what I tried to say in the second paragraph of the original post, which was too cumbersome. My concern is that this behavior might annoy people too much so they start to disable the lint at a large scale like the example from I'm not sure if checking the number of variables in tests is worth to implement because some people including me tend to put multiple tests in one function like both |
I would suggest putting all the self comparison tests into their own test function and put an allow on just that test. Only helps if people actually do that though. I think it's better to keep checking on test code. It's only needed for non-derived With the example from |
How bout this? macro_rules! assert_eq_self {
($e:expr) => {
#[allow(clippy::eq_op)]
assert_eq!($e, $e);
};
} |
My apologies for a late reply. There were good arguments and interesting suggestions here. However, to my surprise, my original suggestion is implemented (#7811) independently from this issue. I think the current state is good enough, so I'm closing this issue for now. |
The
eq_op
lint has a quite large number ofallow
s, ranking in "The most commonly ignored lints" (#5418), and it seems the number has largely increased because of the inclusion of theassert!
family (#6167). I've looked at some of the details and found the overwhelming majority was in test code to ensure they implemented functions and traits likePartialEq
correctly; here and here for example.I'm not sure if I consider this case as a false positive, but legit supression at this scale doesn't seem right although no one except this comment reported this at the moment. However, disabling in test code altogether makes a new FN in case of unintensional
eq_op
s. If Clippy don't do this, it means the intension of this lint is silence it in these tests at the smallest scale possible so it can catch other mistakes in test code.I'd like to ask other people if trading off the FN for eliminating this FP (sort of) is worth or not though I'm in favour of disabling
eq_op
in test code.As a bonus, this can close #6635 nicely.
The implementation will probably be detecting
#[test]
attriubtes so the minimal repro (?) would be:I expected to see this happen: no errors
Instead, this happened (with
--all-targets
):Meta
cargo clippy -V
: clippy 0.1.51 (2fd73fa 2021-03-23)rustc -Vv
:The text was updated successfully, but these errors were encountered: