Apply documentation changes that were applied in the repo docs.scala-lang

Apply the changes that were applied in the repo scala/docs.scala-lang, since commit 113f485c10c9143d9a5f081974a87061903b5a0d within the tree `_scala3-reference`.

Author: julienrf

docs/_docs/reference/changed-features/pattern-matching.md

@@ -94,7 +94,7 @@ A usage of a variadic extractor is irrefutable if one of the following condition
 ## Boolean Match
 
 - `U =:= Boolean`
-- Pattern-matching on exactly `0` pattern
+- Pattern-matching on exactly `0` patterns
 
 For example:
 

docs/_docs/reference/contextual/derivation.md

@@ -330,7 +330,7 @@ given eqProduct[A](using inst: K0.ProductInstances[Eq, A]): Eq[A] with
   )
 
 inline def derived[A](using gen: K0.Generic[A]): Eq[A] =
-  gen.derive(eqSum, eqProduct)
+  gen.derive(eqProduct, eqSum)
 ```
 
 The framework described here enables all three of these approaches without mandating any of them.

docs/_docs/reference/contextual/using-clauses.md

@@ -43,7 +43,7 @@ def maximum[T](xs: List[T])(using Ord[T]): T =
   xs.reduceLeft(max)
 ```
 
-`maximum` takes a context parameter of type `Ord` only to pass it on as an
+`maximum` takes a context parameter of type `Ord[T]` only to pass it on as an
 inferred argument to `max`. The name of the parameter is left out.
 
 Generally, context parameters may be defined either as a full parameter list `(p_1: T_1, ..., p_n: T_n)` or just as a sequence of types `T_1, ..., T_n`. Vararg parameters are not supported in `using` clauses.

docs/_docs/reference/metaprogramming/staging.md

@@ -60,7 +60,7 @@ impose the following restrictions on the use of splices.
 The framework as discussed so far allows code to be staged, i.e. be prepared
 to be executed at a later stage. To run that code, there is another method
 in class `Expr` called `run`. Note that `$` and `run` both map from `Expr[T]`
-to `T` but only `$` is subject to the PCP, whereas `run` is just a normal method.
+to `T` but only `$` is subject to the [PCP](./macros.md#the-phase-consistency-principle), whereas `run` is just a normal method.
 `scala.quoted.staging.run` provides a `Quotes` that can be used to show the expression in its scope.
 On the other hand `scala.quoted.staging.withQuotes` provides a `Quotes` without evaluating the expression.
 

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

@@ -67,7 +67,7 @@ use of the match type as the return type):
 ```scala
 def leafElem[X](x: X): LeafElem[X] = x match
   case x: String      => x.charAt(0)
-  case x: Array[t]    => leafElem(x(9))
+  case x: Array[t]    => leafElem(x(0))
   case x: Iterable[t] => leafElem(x.head)
   case x: AnyVal      => x
 ```

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

@@ -32,7 +32,7 @@ scala> val name = UserName("Eve")
 val name: UserName = UserName(Eve)
 
 scala> if true then name else password
-val res2: Object & Product = UserName(Eve)
+val res2: Object = UserName(Eve)
 
 scala> val either: Password | UserName = if true then name else password
 val either: Password | UserName = UserName(Eve)

docs/_docs/reference/other-new-features/matchable.md

@@ -119,10 +119,10 @@ For instance, consider the definitions
 
 ```scala
 opaque type Meter = Double
-def Meter(x: Double) = x
+def Meter(x: Double): Meter = x
 
 opaque type Second = Double
-def Second(x: Double) = x
+def Second(x: Double): Second = x
 ```
 
 Here, universal `equals` will return true for
@@ -134,6 +134,7 @@ Here, universal `equals` will return true for
 even though this is clearly false mathematically. With [multiversal equality](../contextual/multiversal-equality.md) one can mitigate that problem somewhat by turning
 
 ```scala
+  import scala.language.strictEquality
   Meter(10) == Second(10)
 ```
 

docs/_docs/reference/other-new-features/transparent-traits.md

@@ -42,7 +42,7 @@ appear in the inferred type.
 
 The traits [`scala.Product`](https://scala-lang.org/api/3.x/scala/Product.html), [`java.io.Serializable`](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/io/Serializable.html) and [`java.lang.Comparable`](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Comparable.html)
 are treated automatically as transparent. Other traits are turned into transparent traits using the modifier `transparent`. Scala 2 traits can also be made transparent
-by adding a [`@transparentTrait`](https://scala-lang.org/api/3.x/scala/annotation/transparentTrait.html) annotation. This annotation is defined in [`scala.annotation`](https://scala-lang.org/api/3.x/scala/annotation.html). It will be deprecated and phased out once Scala 2/3 interopability is no longer needed.
+by adding a [`@transparentTrait`](https://scala-lang.org/api/3.x/scala/annotation/transparentTrait.html) annotation. This annotation is defined in [`scala.annotation`](https://scala-lang.org/api/3.x/scala/annotation.html). It will be deprecated and phased out once Scala 2/3 interoperability is no longer needed.
 
 Typically, transparent traits are traits
 that influence the implementation of inheriting classes and traits that are not usually used as types by themselves. Two examples from the standard collection library are:

docs/_docs/reference/syntax.md

@@ -115,7 +115,7 @@ given     if        implicit  import    lazy      match     new
 null      object    override  package   private   protected return
 sealed    super     then      throw     trait     true      try
 type      val       var       while     with      yield
-:         =         <-        =>        <:        :>        #
+:         =         <-        =>        <:        >:        #
 @         =>>       ?=>
 ```