Do not invoke hashCode for UInt

[JakeWharton]

It is backed by an Int whose hashCode is the identity function.

Before:

public int hashCode();
  Code:
     0: aload_0
     1: getfield      #13                 // Field uint:I
     4: invokestatic  #35                 // Method kotlin/UInt."hashCode-impl":(I)I
     7: istore_1
     8: iload_1
     9: bipush        31
    11: imul
    12: aload_0
    13: getfield      #17                 // Field long:J
    16: invokestatic  #40                 // Method java/lang/Long.hashCode:(J)I
    19: iadd
    20: istore_1
    21: iload_1
    22: ireturn

After:

public int hashCode();
  Code:
     0: aload_0
     1: getfield      #13                 // Field uint:I
     4: istore_1
     5: iload_1
     6: bipush        31
     8: imul
     9: aload_0
    10: getfield      #17                 // Field long:J
    13: invokestatic  #34                 // Method java/lang/Long.hashCode:(J)I
    16: iadd
    17: istore_1
    18: iload_1
    19: ireturn

Refs #204

[drewhamilton]

Is T.hashCode-impl generated for all value classes, and does it always defer to the underlying type? If so, maybe as a followup this logic should be broadened to all Int-holding value classes.

[JakeWharton]

Is T.hashCode-impl generated for all value classes

Yes

and does it always defer to the underlying type?

Today it does, but in the future it will not. In the same way you can override toString(), overriding equals and hashCode is coming.

[drewhamilton]

We can probably find a way to check whether it's overridden though.

[JakeWharton]

Unfortunately that's not sufficient as it could be in a different compilation unit (e.g., a library) and be recompiled with a custom hashCode without the Poko-annotated class ever having being recompiled.