Clippy lints / Correctness
Clippy lint · Correctness · checked with Clippy 0.1.99
clippy::derived_hash_with_manual_eq: Lints against manual PartialEq implementations for types with a derived Hash implementation
What it meansLints against manual PartialEq implementations for types with a derived Hash implementation. It is in the correctness group and denied by default (the build fails).
Does it matter?
The implementation of these traits must agree (for example for use with HashMap) so it’s probably a bad idea to use a default-generated Hash implementation with an explicitly defined PartialEq. In particular, the following must hold for any type: k1 == k2 ⇒ hash(k1) == hash(k2)
Code that is almost certainly wrong. Denied by default: the build fails until you fix it or allow it.
How to fix it
Clippy does not fix this one automatically. Change the code by hand:
Flagged
#[derive(Hash)]
struct Foo;
impl PartialEq for Foo {
...
}
Turn it off, or on
Allow it where it does not fit your code, as narrowly as you can:
On one item
#[allow(clippy::derived_hash_with_manual_eq)]
fn my_function() { /* ... */ }Whole crate (Cargo.toml)
[lints.clippy]
derived_hash_with_manual_eq = "allow"One run
cargo clippy -- -A clippy::derived-hash-with-manual-eqThe [lints] table needs Rust 1.74 or newer. In a workspace, put it under [workspace.lints.clippy] and add [lints] workspace = true to each member.
Clippy's own documentation
What it does
Lints against manual PartialEq implementations for types with a derived Hash
implementation.
Why is this bad?
The implementation of these traits must agree (for
example for use with HashMap) so it’s probably a bad idea to use a
default-generated Hash implementation with an explicitly defined
PartialEq. In particular, the following must hold for any type:
k1 == k2 ⇒ hash(k1) == hash(k2)
Example
#[derive(Hash)]
struct Foo;
impl PartialEq for Foo {
...
}
Past names
- derive_hash_xor_eq
From the Clippy lint list (0.1.99), part of the Rust project, MIT or Apache-2.0. Official entry.
Related lints
- char_indices_as_byte_indicesChecks for usage of a character position yielded by .chars().enumerate() in a context where a byte index is expected, such as an argument to a specific str method or indexing into a str or String
- deprecated_semverthe since field must contain a semver-compliant version
- derive_ord_xor_partial_ordLints against manual PartialOrd and Ord implementations for types with a derived Ord or PartialOrd 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
- eq_opChecks for equal operands to comparison, logical and bitwise, difference and division binary operators (==, >, etc., &&, ||, &, |, ^, - and /)
All 847 Clippy lints · Rust compiler errors · Cargo.toml checker
Up next
Related lintclippy::char_indices_as_byte_indicesChecks for usage of a character position yielded by .chars().enumerate() in a context where a byte index is expected, such as an argument to a specific str method or indexing into a str or StringRead it next →Did this answer your question?