derive_partial_eq_without_eq should acknowledge the constraint it adds

Summary

The derive_partial_eq_without_eq lint and its documentation recommends deriving Eq whenever PartialEq is implemented on a public type. However, doing so may constrain the evolution of a library: adding derive(Eq) prevents later adding a private field, or public field or variant in a non_exhaustive enum or struct, which contains an !Eq type such as f64.

Notably, Clippy reported this lint on my library's non-exhaustive error enums — types that are more likely than most to gain new variants with new kinds of data.

At a minimum, the lint documentation should acknowledge that adding Eq constrains future choices.

Lint Name

derive_partial_eq_without_eq

Reproducer

I tried this code:

#[derive(Clone, Debug, PartialEq)]
pub struct Value {
    x: bool,
    // y: f64,            // adding this line would not be a breaking change, but it conflicts with `derive(Eq)`
}

I saw this happen:

warning: you are deriving `PartialEq` and can implement `Eq`
 --> src/lib.rs:1:24
  |
1 | #[derive(Clone, Debug, PartialEq)]
  |                        ^^^^^^^^^ help: consider deriving `Eq` as well: `PartialEq, Eq`
  |
  = note: `#[warn(clippy::derive_partial_eq_without_eq)]` on by default
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#derive_partial_eq_without_eq

Version

Tested with clippy 0.1.63 (2022-06-27 2f3ddd9) on Rust Playground

(The original detection was with `rustc 1.64.0-nightly (c80c4b8fd 2022-06-26)` — sorry, neither my CI nor the Playground provides `rustc -Vv` output)

Additional Labels

No response

Start by locating the documentation for the derive_partial_eq_without_eq lint and review its recommendation against the provided Value reproducer. Update the explanation so it acknowledges that deriving Eq can constrain future API evolution, then verify the rendered lint documentation and relevant documentation checks.