docs: apply snippet compiler on new types reference docs

docs/_docs/reference/new-types/dependent-function-types-spec.md

@@ -25,7 +25,7 @@ methods with a dependent result type. Dependent function types desugar to
 refinement types of `scala.FunctionN`. A dependent function type
 `(x1: K1, ..., xN: KN) => R` of arity `N` translates to:
 
-```scala
+```scala sc:nocompile
 FunctionN[K1, ..., Kn, R']:
   def apply(x1: K1, ..., xN: KN): R
 ```

docs/_docs/reference/new-types/dependent-function-types.md

@@ -7,7 +7,7 @@ nightlyOf: https://docs.scala-lang.org/scala3/reference/new-types/dependent-func
 A dependent function type is a function type whose result depends
 on the function's parameters. For example:
 
-```scala
+```scala sc-name:entry
 trait Entry { type Key; val key: Key }
 
 def extractKey(e: Entry): e.Key = e.key          // a dependent method
@@ -28,7 +28,7 @@ because there was no type that could describe them.
 
 In Scala 3 this is now possible. The type of the `extractor` value above is
 
-```scala
+```scala sc:nocompile
 (e: Entry) => e.Key
 ```
 
@@ -41,7 +41,7 @@ instance of the [`Function1` trait](https://scala-lang.org/api/3.x/scala/Functio
 are also represented as instances of these traits, but they get an additional
 refinement. In fact, the dependent function type above is just syntactic sugar for
 
-```scala
+```scala sc:nocompile
 Function1[Entry, Entry#Key]:
   def apply(e: Entry): e.Key
 ```

docs/_docs/reference/new-types/intersection-types.md

@@ -34,7 +34,7 @@ has member methods `reset` and `add`.
 If a member appears in both `A` and `B`, its type in `A & B` is the intersection
 of its type in `A` and its type in `B`. For instance, assume the definitions:
 
-```scala
+```scala sc:nocompile
 trait A:
   def children: List[A]
 
@@ -59,7 +59,7 @@ must make sure that all inherited members are correctly defined.
 So if one defines a class `C` that inherits `A` and `B`, one needs
 to give at that point a definition of a `children` method with the required type.
 
-```scala
+```scala sc:nocompile
 class C extends A, B:
   def children: List[A & B] = ???
 ```

docs/_docs/reference/new-types/match-types.md

@@ -16,7 +16,7 @@ type Elem[X] = X match
 
 This defines a type that reduces as follows:
 
-```scala
+```scala sc:nocompile
 Elem[String]       =:=  Char
 Elem[Array[Int]]   =:=  Int
 Elem[List[Float]]  =:=  Float
@@ -28,7 +28,7 @@ subtypes of each other.
 
 In general, a match type is of the form
 
-```scala
+```scala sc:nocompile
 S match { P1 => T1 ... Pn => Tn }
 ```
 
@@ -37,7 +37,7 @@ variables in patterns start with a lower case letter, as usual.
 
 Match types can form part of recursive type definitions. Example:
 
-```scala
+```scala sc-name:leafelm
 type LeafElem[X] = X match
   case String => Char
   case Array[t] => LeafElem[t]
@@ -64,7 +64,7 @@ Match types can be used to define dependently typed methods. For instance, here
 is the value level counterpart to the `LeafElem` type defined above (note the
 use of the match type as the return type):
 
-```scala
+```scala sc-compile-with:leafelm
 def leafElem[X](x: X): LeafElem[X] = x match
   case x: String      => x.charAt(0)
   case x: Array[t]    => leafElem(x(0))
@@ -198,14 +198,14 @@ Since reduction is linked to subtyping, we already have a cycle detection
 mechanism in place. As a result, the following will already give a reasonable
 error message:
 
-```scala
+```scala sc:nocompile
 type L[X] = X match
   case Int => L[X]
 
 def g[X]: L[X] = ???
 ```
 
-```scala
+```scala sc:nocompile
    |  val x: Int = g[Int]
    |                ^
    |Recursion limit exceeded.

docs/_docs/reference/new-types/polymorphic-function-types.md

@@ -26,7 +26,7 @@ which can be passed as parameters to other functions, or returned as results.
 
 In Scala 3 this is now possible. The type of the `bar` value above is
 
-```scala
+```scala sc:nocompile
 [A] => List[A] => List[A]
 ```
 
@@ -48,7 +48,7 @@ a data type to represent the expressions of a simple language
 (consisting only of variables and function applications)
 in a strongly-typed way:
 
-```scala
+```scala sc-name:expr
 enum Expr[A]:
   case Var(name: String)
   case Apply[A, B](fun: Expr[B => A], arg: Expr[B]) extends Expr[A]
@@ -60,7 +60,8 @@ This requires the given function to be polymorphic,
 since each subexpression may have a different type.
 Here is how to implement this using polymorphic function types:
 
-```scala
+```scala sc-compile-with:expr sc-name:mapsubexpr
+import Expr.*
 def mapSubexpressions[A](e: Expr[A])(f: [B] => Expr[B] => Expr[B]): Expr[A] =
   e match
     case Apply(fun, arg) => Apply(f(fun), f(arg))
@@ -71,7 +72,7 @@ And here is how to use this function to _wrap_ each subexpression
 in a given expression with a call to some `wrap` function,
 defined as a variable:
 
-```scala
+```scala sc-compile-with:mapsubexpr
 val e0 = Apply(Var("f"), Var("a"))
 val e1 = mapSubexpressions(e0)(
   [B] => (se: Expr[B]) => Apply(Var[B => B]("wrap"), se))

docs/_docs/reference/new-types/type-lambdas-spec.md

@@ -22,7 +22,7 @@ Only the upper bound `U` can be F-bounded, i.e. `X` can appear in it.
 ## Subtyping Rules
 
 Assume two type lambdas
-```scala
+```scala sc:nocompile
 type TL1  =  [X >: L1 <: U1] =>> R1
 type TL2  =  [X >: L2 <: U2] =>> R2
 ```
@@ -40,11 +40,11 @@ its eta expansion. I.e, `List = [X] =>> List[X]`. This allows type constructors
 ## Relationship with Parameterized Type Definitions
 
 A parameterized type definition
-```scala
+```scala sc:nocompile
 type T[X] = R
 ```
 is regarded as a shorthand for an unparameterized definition with a type lambda as right-hand side:
-```scala
+```scala sc:nocompile
 type T = [X] =>> R
 ```
 If the type definition carries `+` or `-` variance annotations,
@@ -60,15 +60,15 @@ type F2 = [A, B] =>> A => B
 and at the same time it is checked that the parameter `B` appears covariantly in `A => B`.
 
 A parameterized abstract type
-```scala
+```scala sc:nocompile
 type T[X] >: L <: U
 ```
 is regarded as shorthand for an unparameterized abstract type with type lambdas as bounds.
-```scala
+```scala sc:nocompile
 type T >: ([X] =>> L) <: ([X] =>> U)
 ```
 However, if `L` is `Nothing` it is not parameterized, since `Nothing` is treated as a bottom type for all kinds. For instance,
-```scala
+```scala sc:nocompile
 type T[X] <: X => X
 ```
 is expanded to
@@ -81,20 +81,20 @@ type T >: ([X] =>> Nothing) <: ([X] =>> X => X)
 ```
 
 The same expansions apply to type parameters. For instance,
-```scala
+```scala sc:nocompile
 [F[X] <: Coll[X]]
 ```
 is treated as a shorthand for
-```scala
+```scala sc:nocompile
 [F >: Nothing <: [X] =>> Coll[X]]
 ```
 Abstract types and opaque type aliases remember the variances they were created with. So the type
-```scala
+```scala sc:nocompile
 type F2[-A, +B]
 ```
 is known to be contravariant in `A` and covariant in `B` and can be instantiated only
 with types that satisfy these constraints. Likewise
-```scala
+```scala sc:nocompile
 opaque type O[X] = List[X]
 ```
 `O` is known to be invariant (and not covariant, as its right-hand side would suggest). On the other hand, a transparent alias

docs/_docs/reference/new-types/type-lambdas.md

@@ -7,7 +7,7 @@ nightlyOf: https://docs.scala-lang.org/scala3/reference/new-types/type-lambdas.h
 A _type lambda_ lets one express a higher-kinded type directly, without
 a type definition.
 
-```scala
+```scala sc:nocompile
 [X, Y] =>> Map[Y, X]
 ```
 

docs/_docs/reference/new-types/union-types-spec.md

@@ -13,19 +13,19 @@ Syntactically, unions follow the same rules as intersections, but have a lower p
 `|` is also used in pattern matching to separate pattern alternatives and has
 lower precedence than `:` as used in typed patterns, this means that:
 
-```scala
+```scala sc:nocompile
 case _: A | B => ...
 ```
 
 is still equivalent to:
 
-```scala
+```scala sc:nocompile
 case (_: A) | B => ...
 ```
 
 and not to:
 
-```scala
+```scala sc:nocompile
 case _: (A | B) => ...
 ```
 
@@ -36,14 +36,17 @@ case _: (A | B) => ...
 - Like `&`, `|` is commutative and associative:
 
   ```scala
-  A | B =:= B | A
-  A | (B | C) =:= (A | B) | C
+  // A | B =:= B |A
+  def commutative[A,B] = summon[(A|B) =:= (B|A)]
+  // A | (B | C) =:= (A | B) | C
+  def associative[A,B,C] = summon[(A | (B | C)) =:= ((A | B) | C)] 
   ```
 
 - `&` is distributive over `|`:
 
   ```scala
-  A & (B | C) =:= A & B | A & C
+  // A & (B | C) =:= A & B | A & C
+  def distributive[A,B,C] = summon[(A & (B | C)) =:= (A & B | A & C)]
   ```
 
 From these rules it follows that the _least upper bound_ (LUB) of a set of types
@@ -95,18 +98,19 @@ The join of `A | B` is `C[A | B] & D & X` and the visible join of `A | B` is `C[
 
 We distinguish between hard and soft union types. A _hard_ union type is a union type that's explicitly
 written in the source. For instance, in
-```scala
-val x: Int | String = ...
+```scala sc-name:hardunion
+val x: Int | String = ???
 ```
 `Int | String` would be a hard union type. A _soft_ union type is a type that arises from type checking
 an alternative of expressions. For instance, the type of the expression
-```scala
+```scala sc-name:softunion
 val x = 1
 val y = "abc"
-if cond then x else y
+val cond: Boolean = ???
+val xy = if cond then x else y
 ```
 is the soft unon type `Int | String`. Similarly for match expressions. The type of
-```scala
+```scala sc-compile-with:softunion
 x match
   case 1 => x
   case 2 => "abc"
@@ -152,7 +156,7 @@ The members of a union type are the members of its join.
 The following code does not typecheck, because method `hello` is not a member of
 `AnyRef` which is the join of `A | B`.
 
-```scala
+```scala sc:nocompile
 trait A { def hello: String }
 trait B { def hello: String }
 
@@ -162,6 +166,9 @@ def test(x: A | B) = x.hello // error: value `hello` is not a member of A | B
 On the other hand, the following would be allowed
 
 ```scala
+trait D
+trait E
+
 trait C { def hello: String }
 trait A extends C with D
 trait B extends C with E