SIP-56: Better foundations for match types

[sjrd]

Implementation of SIP-56: Proper Specification for Match Types.

[soronpo]

@sjrd Can you please take a look at this example that yields a recursion limit error (this doesn't work also on the current match type system)?

type TupleOfRecur[T, UB, Orig] = T match
  case EmptyTuple => Orig
  case UB *: xs => TupleOfRecur[xs, UB, Orig]
  case _ => Nothing
type TupleOf[T, UB] = TupleOfRecur[T, UB, T]

def tupleOfInt[T, Check >: T <: TupleOf[T, Int]](t: T): T = t

val ok = tupleOfInt((1, 2, 3)) //should compile
val err = tupleOfInt((1, 2, "three")) //should fail compilation

This was an attempt of mine to make an upper bound check for tuple contents.
I actually was successful, using a slightly modified version.

sealed trait TupleCheck
type TupleOfRecur[T, UB, Orig] = T match
  case EmptyTuple => TupleCheck
  case UB *: xs => TupleOfRecur[xs, UB, Orig]
  case _ => Nothing

type TupleOf[T, UB] = TupleOfRecur[T, UB, T]

def foo[T, __ >: TupleCheck <: TupleOf[T, Int]](t: T): T = t

val ok = foo((1, 2, 3)) //compiles
val err = foo((1, 2, "three")) //error: Type argument TupleCheck does not conform to upper bound TupleOf[(Int, Int, String), Int]

[sjrd]

That still doesn't work. But I think it is legit that it does not. The recursion includes trying prove T disjoint from EmptyTuple. But T from def tupleOfInt is upper-bounded by TupleOf[T, Int]. So to prove disjointness, according to the rules for ⌈X⌉, it tries to reduce TupleOf[T, Int]. But to do that, it needs to prove disjointness between T and EmptyTuple. etc.

This is a legit cyclic reference to me. Even as a human I don't see how to cut the recursion short. We have to attempt to prove disjointness.

[sjrd]

This is now ready for review. 🎉 The SIP was approved for the design stage, and I rebased and cleaned up everything.

@WojciechMazur Could you please run an Open Community Build based on this PR?

[WojciechMazur]

There seems to be plenty of new comilation errors in community build when compared with the last nightly version - 3.4.0-RC1-bin-20231123-00e9e6b-NIGHTLY:

Project	Version	Build URL	Notes
7mind/izumi	-> 1.2.3	Open CB logs	value == in class Int does not take parameters
avast/scala-server-toolkit	0.18.4	Open CB logs	value == in class Int does not take parameters
avokka/avokka	0.0.8	Open CB logs	value == in class Int does not take parameters
geirolz/toolkit	0.0.11	Open CB logs	value == in class Int does not take parameters
kevin-lee/openai4s	0.1.0-alpha6	Open CB logs	value == in class Int does not take parameters
permutive-engineering/functional-google-clients	1.0.0-RC2	Open CB logs	value == in class Int does not take parameters
typebricks/pureconfig-toggleable	1.0.0	Open CB logs	value == in class Int does not take parameters
fingo/spata	3.1.0	Open CB logs	Mismatch error
foldables-io/skunk-tables	0.0.2	Open CB logs	The match type contains an illegal case
iheartradio/ficus	1.5.2	Open CB logs	The match type contains an illegal case
kory33/s2mc-test	0.2.3	Open CB logs	The match type contains an illegal case
joan38/kubernetes-client	0.10.0	Open CB logs	mill build issue?
johnhungerford/generic-schema	1.2.0	Open CB logs	Mismatch error
kordyjan/pytanie	0.1.7	Open CB logs	Recursion limit exceeded
scalanlp/breeze	2.1.0	Open CB logs	java.lang.StackOverflowError

---

Some of failures I've checked might be expected, eg. in iheartradio/ficus or kory33/s2mc-test we get the following error:

Error:  6 |  type EnumValue[A <: Enumeration] = A match {
Error:    |                                     ^
Error:    |               The match type contains an illegal case:
Error:    |                   case net.ceedubs.ficus.util.EnumerationUtil.Aux[a] => a
Error:    |               (this error can be ignored for now with `-source:3.3`)
Error:  7 |    case Aux[a] => a
Error:  8 |  }

I'm not sure about some of the failures related to usage of @experimental, eg. 7mind/izumi, fmonniot/scala3mock. Unless there was something missing when building the compiler from the dotty-staging branch the created compiler should already be treated as experimental. I would check and adapt our compiler building workflow next time if necessary.

#Edit
The version of compiler build from sources had no SNAPSHOT/NIGHTLY substring though it was not treated as experimental. I would retry the build with this fix.

#Edit 2
Most of the @experimental issues were fixed, in 1 project 7mind/izumi there was found a compilation similar to other fund cases.

[olhotak]

@sjrd Is it supposed to be possible for the targs to be LazyRefs? If they are, the pending set would also fail since LazyRefs compare using reference equality. We could call stripLazyRef here.

I have LazyRefs showing up in a modified version of the compiler in an example with F-bounds, but I don't have a self-contained test case that would make them show up in the unmodified compiler. If it is indeed possible for them to show up, would you have any hints on constructing a test case? In general I have difficulty constructing test cases that even trigger provablyDisjoint to be called on a desired pair of types.