Suggest removing explicit PartialEq implementation that could have been derived

What it does

Suggest that when the explicit implementation of PartialEq matches the one that would have been produced by #[derive(PartialEq)] the user should use the derive. A similar hint could be written for PartialOrd, Hash and perhaps a few others.

Categories (optional)

• Kind: clippy::style

What is the advantage of the recommended code over the original code

• Less code.
• Correctly adjusts as fields are added/renamed.

Drawbacks

Should a user explicitly desire an implementation identical to what would be generated, but not that evolves with the data type in future, the user would have to ignore the lint. I believe that such instances deserve a comment as to why (e.g. that additional fields should not participate in the equality), and attaching that comment to a lint ignore makes a lot of sense.

Example

struct Foo(u64);

impl PartialEq for Foo {
    fn eq(&self, other: &Self) -> bool {
        self.0 == other.0
    }
}

Could be written as:

#[derive(PartialEq)]
struct Foo(u64);

The issue provides no file, test, or entry point; begin by locating existing Clippy style lints that compare explicit trait implementations with derives. Define the matching behavior for PartialEq first, then consider whether the same approach applies to PartialOrd and Hash, with completion requiring the requested lint behavior and coverage for the shown example.