Add explanation to checkCaseClassInheritanceInvariant error msg

[EugeneFlesselle]

Closes #18552 which was actually not an error, see:

scala3/compiler/src/dotty/tools/dotc/typer/RefChecks.scala

Lines 889 to 893 in 73882c5

	/** Check that inheriting a case class does not constitute a variant refinement
	* of a base type of the case class. It is because of this restriction that we
	* can assume invariant refinement for case classes in `constrainPatternType`.
	*/
	def checkCaseClassInheritanceInvariant() =

Co-authored-by: Anna Herlihy herlihyap@gmail.com
Co-authored-by: Natsu Kagami natsukagami@gmail.com

[mbovel]

Looks okay to me!

Two minor questions:

• Is the word "conflicting" really appropriate here? If it is easy to change, maybe I'd write something like "class MB cannot inherit from two instances of base trait M".
• Is it clear that "enabling better GADT constraints" explains why it is implemented that way? Maybe split in a second sentence "This is an implementation limitation that enables better GADT constraints in case class patterns".

[mbovel]

@SimonGuilloud what do you think? Would this message have helped?

[EugeneFlesselle]

If it is easy to change, maybe I'd write something like "class MB cannot inherit from two instances of base trait M".

Technically speaking, it can inherit from two instances

trait M[+T]
case class MAny(id:Int) extends M[Int]
class MInt(id:Int)  extends MAny(id) with M[Any] 
// Ok: they do not conflict since M[Int] <: M[Any]

trait M[+T]
case class Mcc(id:Int)
class MAny(id:Int) extends Mcc(id) with M[Any]
class MInt(id:Int)  extends MAny(id) with M[Int] 
// Ok: the "conflicting" instances are only below the case class

trait M[+T]
case class MAny(id:Int) extends M[Any]
class MInt(id:Int)  extends MAny(id) with M[Int] 
// Error because M[Int] refines M[Any] which is a base type of an intermediate case class

---

Is it clear that "enabling better GADT constraints" explains why it is implemented that way? Maybe split in a second sentence "This is an implementation limitation that enables better GADT constraints in case class patterns".

I agree that's better 👍

[SimonGuilloud]

I think it is certainly better ("This error is blatantly wrong" => "I don't understand the message but alright").
It's the second time I encounter a "bug" which is actually a limitation due to GADT reasoning, but I'm not even sure what it actually does. So for me the solution was to make every class non-case and reimplement hashCode and equals every time. Not great and bug prone, but that's the best I found.