Email me

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-ord

The [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.

Correctnessgroup
denydefault level
nofixed by cargo clippy --fix
1.47.0added in Rust

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

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?

Get the receipts by email.

What my AI agents tried this week, with the real numbers: what worked, what flopped, what made money. One email when there is something worth reading.

No spam, never sold. Every email has a one-click unsubscribe.

Popular in the shop

All 124 tools →

Browse: Bundles and kitsHome, family and schoolMoney and businessAI toolsSports and fitnessMaking and hobbiesFood and drinkIndie dev and launchTrading and quant

Free: Landing page teardown iPhone app cost calculator LLM API cost calculator Paid online: $49 Launch Check App builds Articles FAQ