Compare productPrefix in synthetic case class canEqual

[lrytz]

Since 2.13, case class hashCode mixes in the hash code of the productPrefix string. The synthetic equals method has fallen out of sync in that regard, so two instances can be equal but have different hash codes.

This commit changes the synthetic canEqual method to also compare the productPrefix of the two instances.

Scala 3 forward port of scala/scala#10859, for scala/bug#13033.

[lrytz]

this is a semantic change, in 3.5.0 and 2.13.15, c == new D is true.

[lrytz]

@sjrd pointed out that the change introduces this discrepancy:

scala> case class C(x: Int)
scala> class D extends C(1) { override def productPrefix = "D" }

scala> new D match { case C(1) => true }
val res0: Boolean = true

scala> new D == C(1)
val res1: Boolean = false

[lrytz]

What it fixes is this:

scala> case class C(x: Int)
scala> class D extends C(1) { override def productPrefix = "D" }
scala> val s = collection.mutable.HashSet(C(1))

scala> s.contains(new D)
val res0: Boolean = false

scala> s.exists(_ == new D)
val res1: Boolean = true

[sjrd]

Have we considered removing productPrefix from the hashCode computation instead?

Should we perhaps use a "hard-coded" seed instead (computed at compile-time from the hash code of the full class name, for example)?

[lrytz]

Sorry, I missed your reply.

I initially suggested that on private chat, but @retronym pointed out that then case class hash codes would be inconsistent with MurmurHash3.productHash. Not sure what that implications that would have.

[sjrd]

I don't think that's a problem. Case classes don't compare equal to other Products with the same elements.