`Chain#hashCode is consistent with List#hashCode` failure

[armanbilge]

4720e63

  ==> X cats.tests.ChainSuite.Chain#hashCode is consistent with List#hashCode  0.026s munit.FailException: tests/shared/src/test/scala/cats/tests/ChainSuite.scala:413 assertion failed
  412:    forAll { (x: Chain[Int]) =>
  413:      assert(x.hashCode === (x.toList.hashCode))
  414:    }
  
  Failing seed: h-VzfxGoWRYOWssSCMMg3QRR7tMwMmDVoJU5Y-Fdj-D=
  You can reproduce this failure by adding the following override to your suite:
  
    override def scalaCheckInitialSeed = "h-VzfxGoWRYOWssSCMMg3QRR7tMwMmDVoJU5Y-Fdj-D="
  
  Falsified after 18 passed tests.
  > ARG_0: Chain(-1, -1, -1, -1)

[rossabaker]

I ran out of time, but here's a hint:

scala> Chain(-1, -1).##
val res18: Int = 202645784

scala> Chain(-1, -1, -1).##
val res19: Int = 202645784

scala> List(-1, -1).##
val res20: Int = 202645784

scala> List(-1, -1, -1).##
val res21: Int = 1126045640

scala> cats.kernel.instances.StaticMethods.orderedHash(List(-1, -1).iterator)
val res26: Int = 202645784

scala> cats.kernel.instances.StaticMethods.orderedHash(List(-1, -1, -1).iterator)
val res27: Int = 202645784

[rossabaker]

It's probably this: scala/scala#10912

[rossabaker]

I don't like to repeal laws, but in my opinion, this law is an overspecification, particularly when the standard library may change hash codes in a patch release.

The linked change makes a better hash code, and the JVM only guarantees stability within a single run. I'd be open to adopting that, too.

[johnynek]

This law feels weird to me too. Testing hash is already kind of hard since a constant value should probably pass any set of laws.

I can see changing the test that the hash matches a specific implementation but that's not such a great test either honestly.