Derived Hash is incorrect if PartialEq is not derived

[untitaker]

This should not work:

#[derive(Hash)]
struct Foo { bogus: usize };

impl PartialEq for Foo {
    fn eq(&self, _: &Foo) -> bool { true }
}

impl Eq for Foo {};

playpen

We have this in the docs of std::hash::Hash:

k1 == k2 -> hash(k1) == hash(k2)

Since all Foos are equal, their hashes must always be the same too, but the derived hash impl doesn't behave that way (see playpen).

One way to avoid this issue is to give up on deriving Hash when PartialEq isn't automatically derived.

[Gankra]

Enforcing this rigorously seems unreasonable, but one could lint against this. See https://github.com/Manishearth/rust-clippy/issues/430

[untitaker]

I don't know, rust-clippy mostly seems to be about warning about either ugly or noop/inefficent code, while deriving Hash without deriving PartialEq leads to actual bugs.

[apasel422]

I think a lint with a warning here would be appropriate.

[steveklabnik]

Since new lints have a big impact on users of rustc, the policy is that they should go through the RFC process like other user-facing changes. As such, I'm going to give this one a close, but if anyone comes across this ticket and wants this lint, consider adding it to clippy and/or writing up an RFC. Thanks!

[untitaker]

Would it be appropriate to just refile this issue against rust-lang/rfcs for now?

[untitaker]

whatever, continued at rust-lang/rfcs#1499