Duplicate symbol on bridge generation

[odersky]

We get a duplicate generated symbol for fromIterableWithSameElemType in class ArrOps when compiling iarray.scala:

import scala.reflect.ClassTag

class Arr[T](private val underlying: scala.Array[T]) extends AnyVal

trait SeqMonoTransforms[+A, +Repr] extends Any {
  protected[this] def fromIterableWithSameElemType(): Repr
}

class ArrOps[A](val xs: Arr[A]) extends AnyRef with SeqMonoTransforms[A, Arr[A]] {
  def fromIterableWithSameElemType(): Arr[A] = xs
}

object Test {
  def main(args: Array[String]) =
    println(new ArrOps(new Arr(Array(1, 2, 3))).fromIterableWithSameElemType)
}

If we compile this with -Ycheck:erasure, we get:

exception occurred while compiling iarray.scala
Exception in thread "main" class dotty.tools.dotc.reporting.diagnostic.messages$Error at iarray.scala:9: method fromIterableWithSameElemType is already defined as method fromIterableWithSameElemType: ()ErasedValueType(Arr, Object)
(the definitions have matching type signatures)
at dotty.tools.dotc.reporting.Reporting$class.error(Reporter.scala:85)
at dotty.tools.dotc.core.Contexts$Context.error(Contexts.scala:57)
at dotty.tools.dotc.typer.Checking$$anonfun$checkDecl$1$1.doubleDefError$1(Checking.scala:548)
at dotty.tools.dotc.typer.Checking$$anonfun$checkDecl$1$1.apply(Checking.scala:551)
at dotty.tools.dotc.typer.Checking$$anonfun$checkDecl$1$1.apply(Checking.scala:540)
at scala.collection.immutable.List.foreach(List.scala:381)

[odersky]

BTW: Here is scalac's behavior, which is also wrong (see SI-10150)

iarray.scala:10: error: bridge generated for member method fromIterableWithSameElemType: ()Arr[A] in class ArrOps
which overrides method fromIterableWithSameElemType: ()Repr in trait SeqMonoTransforms
clashes with definition of the member itself;
both have erased type ()Object
def fromIterableWithSameElemType(): Arr[A] = xs
^
one error found

[DarkDimius]

In this example there indeed should be two methods with same signature with our current compilation scheme:

• one inherited from SeqMonoTransforms that returns Repr,
• another from ArrOps that returns erazed version of Arr[A] which is A.

Both those methods have same names and their entire JVM signature is the very same.

This can be fixed by making value-classes method be name-mangled, ie method that returns Arr[A] will have a name fromIterableWithSameElemType$vc.

[DarkDimius]

Note that you cant skip generation of the bridge, as callsites that observe the instance of the class as SeqMonoTransforms would expect fromIterableWithSameElemType:()Object to return Repr, while callsites that observe ArrOps would expect fromIterableWithSameElemType:()Object to return A.
As A and ArrOps are unrelated the same method can't satisfy both contracts.

[odersky]

@DarkDimius I don't understand. According to Scala's typing rules, these methods are in an overriding relationship (both scalac and dotc agree on this). Furthermore, they have the same erasure, so overriding also holds on the JVM level. So, no bridge should be generated.

[odersky]

another from ArrOps that returns erazed version of Arr[A] which is A.

No, the erasure of Arr[A] is Object, not A.

[DarkDimius]

@odersky,

No, the erasure of Arr[A} is Object, not A.

What I've ment here was observable semantics, not erasure:

• SeqMonoTransforms defines a method fromIterableWithSameElemType that semantically should return Repr
• ArrOps defines a methodfromIterableWithSameElemType that should semantically return an scala.Array[A](this method is value-class unboxed version).

Those two methods have different semantics, but the same erazed form, which means that in runtime they will be dispatch to same location that should follow both semantics, and this isn't possible as semantics contradict.

[odersky]

ArrOps defines a methodfromIterableWithSameElemType that should semantically return an A(this method is value-class unboxed version).

No, please have a look at the signature of the value class again. This is simply wrong.

[DarkDimius]

No, please have a look at the signature of the value class again. This is simply wrong.

Fixed a typo, but the message stays the same
It returns the underlying of Arr[T] which is scala.Array[T] with unbounded T, that is erazed to Object.
the same method fromIterableWithSameElemType()Object should both return Repr which is bridge returning Arr[A] and scala.Array[A], which is a value-class underlying

[odersky]

But Repr is scala.Array[T]! I still don't understand. Are you claiming that the two fromIterableWithSameElementType methods are not in an overriding relationship?

[DarkDimius]

Consider this, simpler example:

class A(a: Any) extends AnyVal
abstract class Super[T] {
 def id(arg: T): T
}

class Child extends Super[A] {
  def id(a: A): A = a
}

how many methods should there be defined and implemented in Child(including bridges)?
Given our semantics, there should be 3:

• the one defined in source A => A
• the unboxed version of the previous one Underlying(A) => Underlying(A), where Underlying is a function that given a type returns underlying type of a value class, Underlying(A) == Object
• the method that bridges to Super, which is T => T, which, given T is unbounded is erazed to Object => Object.

Note that two last methods clash on erasure.

[DarkDimius]

But Repr is scala.Array[T]!

Repr isn't scala.Array[T], Repr is Arr[A], whose unboxed version would indeed have been scala.Array[T] in your example, but as super class is a generic location you can't let unboxed version escape there without breaking semantics.