clippy::eq_op: Checks for equal operands to comparison, logical and bitwise, difference and division binary operators (==, >, etc., &&, ||, &, |, ^, - and /)

if x + 1 == x + 1 {}

// or

assert_eq!(a, a);

#[allow(clippy::eq_op)]
fn my_function() { /* ... */ }

[lints.clippy]
eq_op = "allow"

cargo clippy -- -A clippy::eq-op

Clippy's own documentation

What it does

Checks for equal operands to comparison, logical and bitwise, difference and division binary operators (==, >, etc., &&, ||, &, |, ^, - and /).

Why is this bad?

This is usually just a typo or a copy and paste error.

Known problems

False negatives: We had some false positives regarding calls (notably racer had one instance of x.pop() && x.pop()), so we removed matching any function or method calls. We may introduce a list of known pure functions in the future.

Example

if x + 1 == x + 1 {}

// or

assert_eq!(a, a);

From the Clippy lint list (0.1.99), part of the Rust project, MIT or Apache-2.0. Official entry.

Related lints

• derived_hash_with_manual_eqLints against manual PartialEq implementations for types with a derived Hash implementation
• eager_transmutethis transmute is always evaluated eagerly, even if the condition is false
• enum_clike_unportable_variantC-like enum variant discriminant is not portable to 32-bit targets
• erasing_opthis operation will always return zero. This is likely not the intended outcome
• if_let_mutexChecks for Mutex::lock calls in if let expression with lock calls in any of the else blocks
• ifs_same_condChecks for consecutive ifs with the same condition

All 847 Clippy lints · Rust compiler errors · Cargo.toml checker