Missing arity check in fromProduct for Tuples

[nicolasstucki]

Compiler version

438dfb0

Minimized code

@main def Test =
  val tup2Mirror = summon[scala.deriving.Mirror.Of[(Int, Int)]]
  val tup2a: (Int, Int) = tup2Mirror.fromProduct((1, 2, 3)) // fails silently and creates (1, 2)
  println(tup2a)
  val tup2b: (Int, Int) = tup2Mirror.fromProduct(Tuple(1)) // crashes with index out of bounds
  println(tup2b)

Output

Exception in thread "main" java.lang.IndexOutOfBoundsException: 1 is out of bounds (min 0, max 0)
        at scala.Product1.productElement(Product1.scala:42)
        at scala.Product1.productElement$(Product1.scala:40)
        at scala.Tuple1.productElement(Tuple1.scala:23)
        at Test$package$$anon$1.fromProduct(Test.scala:4)
        at Test$package$$anon$1.fromProduct(Test.scala:4)
        at Test$package$.Test(Test.scala:6)
        at Test.main(Test.scala:3)

Expectation

fromProduct should assert that the arity of the given tuple is correct. It should fail with a meaningful error message.

[bishabosha]

we can patch this for newly compiled code but its still not going to work when depending on libraries compiled by 3.1.x - but fromProduct is supposed to be unsafe anyway - what if the arity is correct but the element types are wrong?

[nicolasstucki]

What I would propose is instead of generating a new anonymous class for each tuple mirror we could define a class in the library.

Right now we do

val tup2Mirror = 
          {
            final class $anon() extends Object(), Serializable {
              type MirroredMonoType = (Int, Int) // not sure why this is added here
            }
            (new $anon():Object & Serializable)
          }.$asInstanceOf[
              scala.deriving.Mirror.Product{
                MirroredMonoType = (Int, Int); MirroredType = (Int, Int); 
                  MirroredLabel = ("Tuple2" : String)
                ; MirroredElemTypes = (Int, Int); 
                  MirroredElemLabels = (("_1" : String), ("_2" : String))
              }
            
          ]

instead we could define in the library runtime

package scala.runtime
class TupleMirror(arity: Int) extends Mirror.Product {
  def fromProduct(p: scala.Product): MirroredMonoType = 
    assert(p.productArity == arity, "...")
    Tuple.fromProduct(p).asInstanceOf[MirroredMonoType]
}

and then we can infer

val tup2Mirror = 
          new runtime.TupleMirror(2).$asInstanceOf[
              scala.deriving.Mirror.Product{
                MirroredMonoType = (Int, Int); MirroredType = (Int, Int); 
                  MirroredLabel = ("Tuple2" : String)
                ; MirroredElemTypes = (Int, Int); 
                  MirroredElemLabels = (("_1" : String), ("_2" : String))
              }
            
          ]

[nicolasstucki]

This also made me notice that the tuple mirrors are extremely inefficient as each inferred instance creates a new class with a duplication of the same code. This would be solved by the runtime.TupleMirror with or without an arity.

[nicolasstucki]

Furthermore, the runtime.TupleMirror would also work for large tuples (see #15398).

[bishabosha]

this sounds good to me - I didn't quite get before that this change was just for tuples. - and the runtime.TupleMirror should not leak into public apis. would that need to be experimental still?

[nicolasstucki]

We could add the runtime.TupleMirror as experimental in a patch release but we will not be able to use it until the next minor release. Maybe it is cleaner to add the class and change the mirror inference at the same time on the minor release.