TASTy: it seems the internal TypeBox and MatchCase are referenced from TASTy

[sjrd]

I just tried naively moving scala.internal.TypeBox and MatchCase to scala.runtime. If I do that, from a clean build I get:

sbt:scala3> clean
[success] Total time: 0 s, completed 17 nov. 2020 15:08:20
[success] Total time: 0 s, completed 17 nov. 2020 15:08:20
sbt:scala3> scala-comp
{invalid input}
sbt:scala3> scala3-compiler/compile
[info] Compiling 71 Scala sources and 115 Java sources to C:\Users\sjrdo\Documents\Projets\dotty\library\target\scala-3.0.0-M2\classes ...
[info] Compiling 7 Java sources to C:\Users\sjrdo\Documents\Projets\dotty\interfaces\target\classes ...
[info] Unpacking scalajs-ir sources to C:\Users\sjrdo\Documents\Projets\dotty\compiler\target\scala-3.0.0-M2\src_managed\main\scalajs-ir-src...
[error] Bad symbolic reference. A signature
[error] refers to TypeBox/T in package scala.internal which is not available.
[error] It may be completely missing from the current classpath, or the version on
[error] the classpath might be incompatible with the version used when compiling the signature.
[error] -- Error: C:\Users\sjrdo\Documents\Projets\dotty\library\src\scala\IArray.scala:478:21
[error] 478 |    Array.unapplySeq((x: Sup[T]): Array[_ <: T])
[error]     |                     ^
[error]     |                     class TypeBox does not have a member type CAP
[error] Bad symbolic reference. A signature
[error] refers to MatchCase/T in package scala.internal which is not available.
[error] It may be completely missing from the current classpath, or the version on
[error] the classpath might be incompatible with the version used when compiling the signature.
[error] three errors found
[error] (scala3-library / Compile / compileIncremental) Compilation failed
[error] Total time: 2 s, completed 17 nov. 2020 15:08:35

This suggests that those two internal types made it as is in the TASTy of the dotty-library.

They shouldn't be there, as they are implementation details of the compiler, not something that we can justify in TASTy as a language independent of the compilers.

[odersky]

As we have discussed, TypeBox should stay since it is really an encoding of capture conversion, not something special by itself. #10362 solves the MatchCase issue.

[sjrd]

About TypeBox, could you write a sentence or two about where it has an impact? IIUC from the meeting, someone consuming TASTy files for say, static analysis, would have to know about that special type, wouldn't they?

[smarter]

Also, it's not clear to me why we keep TypeBox in Tasty but we drop SkolemType, if we're fine with the unsoudness that comes from removing the latter, then it seems that we could also replace occurences of TypeBox[A,B]#CAP by ? >: A <: B (or do avoidance and use A or B in situations where we can't use a wildcard)

[odersky]

Here's the doc comment of TypeBox

/** A type for skolems that are generated during capture conversion. Capture conversion

• narrows the type of a tree whose type has wildcard arguments. A typical situation
• is a tree t of type C[_ >: L <: U] and an expected type C[X] where X is an
• instantiatable type variable. To be able to instantiate X, we cast the tree to type
• X[$n.CAP] where $n is a fresh skolem type with underlying type TypeBox[L, U].
  */

For downstream users, including macro expansion, this is just a type like any other. There's nothing more we can say about it.

@smarter

it seems that we could also replace occurences of TypeBox[A,B]#CAP by ? >: A <: B

No, since such types are not legal outside of arguments to other types.

(or do avoidance)

No since this would make code ill typed.