derive(Hash) on enum causes hash collision on 32-bit system

[klutzy]

use std::hash::{hash, SipHasher};

#[derive(Hash)]
enum E {
    A = 1,
    B,
}

fn main() {
    let a = hash::<_,   SipHasher>(&E::A);
    let b = hash::<_,   SipHasher>(&E::B);

    println!("{}, {}, {}", a, b, a == b);
}

$ rustc a.rs --target=i686-unknown-linux-gnu && ./a
13715208377448023093, 13715208377448023093, true

Output of -Z unstable-options --pretty=expanded is:

// snip
#[automatically_derived]
impl <__S: ::std::hash::Writer + ::std::hash::Hasher> ::std::hash::Hash<__S>
 for E {
    #[inline]
    fn hash(&self, __arg_0: &mut __S) -> () {
        match (&*self,) {
            (&E::A,) => { ::std::hash::Hash::hash(&1, __arg_0); }
            (&E::B,) => { ::std::hash::Hash::hash(&1us, __arg_0); }
        }
    }
}
// snip

Here A uses 1 (is i32) and B uses 1us for hashing, thus they collide if they have same bit representation.

(was potential issue of #18573)

[steveklabnik]

These APIs have changed a bunch. I think this is the situation today:

use std::hash::Hasher;

#[derive(Hash)]
enum E {
    A = 1,
    B,
}

fn main() {
    let mut hasher = SipHasher::new();

    hasher.write_i32(E::A as i32);
    let a = hasher.finish();

    let mut hasher = SipHasher::new();
    hasher.write_i32(E::B as i32);
    let b = hasher.finish();

    println!("{:?}, {:?}, {:?}", a, b, a == b);
}

I don't have --target=i686-unknown-linux-gnu handy... however, expanding still gives

impl ::std::hash::Hash for E {
    fn hash<__H: ::std::hash::Hasher>(&self, __arg_0: &mut __H) -> () {
        match (&*self,) {
            (&E::A,) => { ::std::hash::Hash::hash(&1, __arg_0); }
            (&E::B,) => { ::std::hash::Hash::hash(&1usize, __arg_0); }
        }
    }
}

the 1 and 1usize are still there, so I'm assuming the issue is.

[ranma42]

cc @ranma42

[apasel422]

This can be addressed the same way as #24270.

[durka]

This seems to be fixed: http://is.gd/tm84D2 (the variants no longer have the same discriminant)

[apasel422]

Isn't that a 64-bit system?

On Saturday, March 5, 2016, Alex Burka notifications@github.com wrote:

This seems to be fixed: http://is.gd/tm84D2

—
Reply to this email directly or view it on GitHub
#21714 (comment).

[durka]

Yes, but it seems like the real bug in the original was enum E { A = 1, B } turning into enum E { A = 1, B = 1} or am I misunderstanding?

[apasel422]

I think it's that in the syntax expansion, one's hash is 1i32 and the
other's is 1isize.

On Saturday, March 5, 2016, Alex Burka notifications@github.com wrote:

Yes, but it seems like the real bug in the original was enum E { A = 1, B
} turning into enum E { A = 1, B = 1} or am I misunderstanding?

—
Reply to this email directly or view it on GitHub
#21714 (comment).

[durka]

@apasel422 I understand now. Working on a fix.