about "Mix in the productPrefix hash statically in case class hashCode" (#11023)

[mr-git]

In PR #11023 breaking changes were introduced, which change the way how compiler generates cases classes.

That change has negative effect at $WORK as same case class compiled with 2.13.16 and 2.13.17 result in different Java bytecode, which leads to different checksum, which is the big no-no in regulated environment.

Effectively, the #11023 change, breaks our ability to upgrade compiler for critical parts of our code past 2.13.16.

In #11023 there is no discussion on whether this change is wise, specially at the "patch" level.

Together with linting change, the 2.13.17 introduces a lot of very annoying changes with deeply cascading impact.

Would it be possible to revert the #11023?

[lrytz]

scala/scala#11023 is indeed a breaking change in terms of runtime semantics, but it fixes a bug. Changing semantics in order to fix a bug is a tradeoff, I agree. We decided to go ahead here, also on Scala 3.

same case class compiled with 2.13.16 and 2.13.17 result in different Java bytecode

This is not a bug, we never had a guarantee for bytecode stability between Scala versions. We only guarantee bytecode stability when re-compiling with the same Scala version (including incremental compilation, i.e., when only re-compiling selected files of a project – I'm not sure this is formally specified, but we treat such instabilities as bugs). And we guarantee binary compatibility of bytecode compiled between Scala versions.

[SethTisue]

specially at the "patch" level.

Note that Scala 2 version numbers are epic.major.minor — not major.minor.patch, as Scala 3 has. You should not be thinking of 2.13.x releases as mere patch upgrades.