Clippy lints / Correctness
Clippy lint · Correctness · checked with Clippy 0.1.99
clippy::derive_ord_xor_partial_ord: Lints against manual PartialOrd and Ord implementations for types with a derived Ord or PartialOrd implementation
What it meansLints against manual PartialOrd and Ord implementations for types with a derived Ord or PartialOrd 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 sort) so it’s probably a bad idea to use a default-generated Ord implementation with an explicitly defined PartialOrd. In particular, the following must hold for any type implementing Ord: k1.cmp(&k2) == k1.partial_cmp(&k2).unwrap()
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(Ord, PartialEq, Eq)]
struct Foo;
impl PartialOrd for Foo {
...
}
Write this instead
#[derive(PartialEq, Eq)]
struct Foo;
impl PartialOrd for Foo {
fn partial_cmp(&self, other: &Foo) -> Option<Ordering> {
Some(self.cmp(other))
}
}
impl Ord 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::derive_ord_xor_partial_ord)]
fn my_function() { /* ... */ }Whole crate (Cargo.toml)
[lints.clippy]
derive_ord_xor_partial_ord = "allow"One run
cargo clippy -- -A clippy::derive-ord-xor-partial-ordThe [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 PartialOrd and Ord implementations for types with a derived Ord
or PartialOrd implementation.
Why is this bad?
The implementation of these traits must agree (for
example for use with sort) so it’s probably a bad idea to use a
default-generated Ord implementation with an explicitly defined
PartialOrd. In particular, the following must hold for any type
implementing Ord:
k1.cmp(&k2) == k1.partial_cmp(&k2).unwrap()
Example
#[derive(Ord, PartialEq, Eq)]
struct Foo;
impl PartialOrd for Foo {
...
}
Use instead:
#[derive(PartialEq, Eq)]
struct Foo;
impl PartialOrd for Foo {
fn partial_cmp(&self, other: &Foo) -> Option<Ordering> {
Some(self.cmp(other))
}
}
impl Ord for Foo {
...
}
or, if you don’t need a custom ordering:
#[derive(Ord, PartialOrd, PartialEq, Eq)]
struct Foo;
From the Clippy lint list (0.1.99), part of the Rust project, MIT or Apache-2.0. Official entry.
Related lints
- cast_slice_different_sizescasting between raw pointers to `[i32]` (element size 4) and `[u8]` (element size 1) does not adjust the count
- 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
- 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
All 847 Clippy lints · Rust compiler errors · Cargo.toml checker
Up next
Related lintclippy::cast_slice_different_sizescasting between raw pointers to `[i32]` (element size 4) and `[u8]` (element size 1) does not adjust the countRead it next →Did this answer your question?