Derived PartialOrd and implemented Ord

Suggestion: if a user writes #[derive(PartialOrd)] and then implements Ord manually, we should issue a warning. This is almost certainly wrong and will lead to problems.

The same applies to PartialEq and Eq.

See rust-lang/rust#40192 for an example.

[LunaBorowska]

Derived PartialEq and implemented Eq is mostly harmless, I don't think it should be linted on. It's necessary if a structure has floating point types which can be proven to not store NaN, and there is no code in Eq trait.

Also, I think writing #[derive(Ord)] and implementing PartialOrd manually should be warned against as well (in fact, it probably should be denied by default - as there is no reason you ever would want to do that, while with #[derive(PartialOrd)] and implementing Ord I can see an use-case for implementing Ord for floating number types).

[LunaBorowska]

Specifically, I think this is the best approach about it:

• impl PartialEq, #[derive(Eq)] - No warnings, deriving Eq is always fine as it has no extra methods.
• #[derive(PartialEq)], impl Eq - Unnecessary warning, if it's not necessary (it's considered necessary if struct has generic parameters without Eq bound or has PartialEq-only types).
• impl PartialOrd, #[derive(Ord)] - Correctness warning.
• #[derive(PartialOrd)], impl Ord - Correctness warning if Ord implementation isn't trivial (an example of trivial implementation would be self.partial_cmp(other).unwrap()). Unnecessary warning if it's not necessary (it's considered necessary if struct has generic parameters without Ord bound or has PartialOrd-only types).

[Ryan1729]

I would like to work on this. Specifically, I would like to create a new derive_ord_xor_partial_ord lint which would work analogously to the derive_hash_xor_partial_eq lint.