improvments for synthetic case class hashCode

[scabug]

In 0e197e89ac there are custom hashCodes being spun for case classes. Some things left to do:

• tragically, specialized classes do not yet benefit. Not sure how to deal with that; I suppose it will have to go into the specialization phase.

• if a class has nothing but generic elements in the product, there's no benefit to unrolling a giant series of "anyHash" calls. May as well just pass the product like before and save the code size.

• Case classes should probably be seeded on the string representation of the class name, like case objects use for their hashcode. Right now everything is seeded wit the MurmurHash3 "product" seed.

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-5781?orig=1
Reporter: @paulp

[scabug]

@paulp said:
More:

• I'm thinking we should always generate the hashCode calculating method, so people can override hashCode and not lose the synthetic. We should do this for equals as well. Sample:

case class Foo(x: Int, y: Int, z: String)

would give us

object Foo {
  def classHashCode(x: Foo): Int = { // custom hashcode calculation }
  def classEquals(x1: Foo, x2: Foo): Boolean = { // custom equals }
  // apply, unapply, etc.
}

class Foo(val x: Int, y: Int, z: String) {
  // now you can do, for instance, this:
  override lazy val hashCode = Foo.classHashCode(this)
}