No Java Signature for mixed-in generic methods

[scabug]

Here the thing I've found during exploration of Java complaining on generics in methods generated for specialization.
The problem also found with method generaited for trait implementation.

An example:

Scala:

trait Test[A] {
	def m( a: A ): A
	def specified(a:A):A = a
}

abstract class T2[A] extends Test[A]

Java:

public class JTest<A> extends T2<A> {
	public A m( A a ) {
		return a;
	}
}

java compiler (-Xlint:unckecked) complains about:

specified(java.lang.Object) in T2 implements specified(A) in Test; return type requires unchecked conversion
found   : java.lang.Object
required: A

JD Java Decompiler shows that generated method is not generic:

public abstract interface Test<A> extends ScalaObject
{
  public abstract A m(A paramA);

  public abstract A specified(A paramA);
}


public abstract class T2<A>
  implements Test<A>, ScalaObject
{
  public Object specified(Object a)
  {
    return Test.class.specified(this, a); } 
  public T2() { Test.class.$$init$$(this); }

}

public class JTest<A> extends T2<A>
{
  public A m(A a)
  {
    return a;
  }
}

}

> scalac -version
Scala compiler version 2.8.0.r22036-b20100526020129 -- Copyright 2002-2010, LAMP/EPFL

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-3486?orig=1
Reporter: Vladimir Kirichenko (razer)

[scabug]

@dragos said:
There's nothing about specialization in this example. Java signatures are missing for mixed in methods.

[scabug]

@adriaanm said:
tricky one!

mixin clones members from the implementation class of a trait to add the forwarding members in the class that mixes in that trait

the problem was that the members from the implementation class are also cloned (implClass in AddInterfaces) -- when a symbol is cloned, it loses its TypeHistory (only the info at cloning time is carried over), and thus the atPhase(currentRun.erasurePhase) that is used to compute the java generic signature (in GenJVM and Erasure) after generics have already been erased, was moot.

The first solution I tried was to have [http://github.com/adriaanm/scala/commit/0acbfe8b29c2055665630861f6fa5b473b3baeb2#diff-1 clone all entries in the type history] of a symbol -- that worked, but caused other subtle problems at other phases when compiling other code.

The [http://github.com/adriaanm/scala/commit/dee5b264dc6ae771d73dd61dc16c367b1f40535e#diff-0 less invasive solution] that I now propose is twofold

• in mixinImplClassMembers in Mixin, clone the member from the trait's interface instead of its implementation class, as the former is polymorphic whereas the latter is not -- this means that we have to compute its info as seen from the implementation class's this type
• perform the clone at the beginning of erasure, since the member from the interface has not been cloned after erasure, it still has the right info from that phase, and update the info at the current phase so that the symbol gets a second entry in its history that is appropriate for this phase

[scabug]

@adriaanm said:
(In r22515) closes #3486. members of implclasses are clones of the original trait members, but cloning discards a symbol's typehistory so that javaSig could not look at the symbol's type before erasure

fixed by having mixin do the cloning at the beginning of erasure and then updating the symbol's info to transform it to be valid in current phase

review by odersky