Specialized class member function not seen as specialized

[scabug]

This could be a duplicate or variant of #5490, but I'm not sure. Given the code:

final class Bar[@specialized(Int) A] {
  private def invoker(f: A => A)(a: A): A = f(a)
  private val specfunc1 = (a: A) => a

  def good(f: A => A, a: A): A = invoker(f)(a)
  def bad(a: A): A = invoker(specfunc1)(a)
}

object Test2 {
  def main(args: Array[String]) {
    val bar = new Bar[Int]
    val specfunc2 = (a: Int) => a

    bar.good(specfunc2, 1)
    bar.bad(1)
  }
}

I attempted to follow the bytecode to see where it goes wrong, but it's not clear to me from the byte code how this transpires. Instead I'm attaching the runtime call tree that shows how Bar$mcI$sp.bad$mcI$sp invokes Bar$mcI$sp.invoker$mcI$sp, which in turn invokes the interface Function1.apply$mcII$sp, and this call is received by a parent class (AbstractFunction1) that unnecessarily boxes/unboxes; so somehow specfunc1 isn't correctly specialized. Ie:

  public int invoker$mcI$sp(scala.Function1<java.lang.Object, java.lang.Object>, int);
    Code:
       0: aload_1       
       1: iload_2       
       2: invokeinterface #25,  2           // InterfaceMethod scala/Function1.apply$mcII$sp:(I)I
       7: ireturn       

Function1$class.apply$mcII$sp bytecode (via jprofiler) shows

 0 aload_0
 1 iload_1
 2 invokestatic #93 <scala/runtime/BoxesRunTime.boxToInteger>
 5 invokeinterface #38 <scala/Function1.apply> count 2
10 invokestatic #62 <scala/runtime/BoxesRunTime.unboxToInt>
13 ireturn

Whereas, when Bar$mcI$sp.good$mcI$sp invokes Bar$mcl$sp.invoker$mcI$sp, the recipient of the invokeinterface is Test2$$anonfun$1.apply$mcII$sp; ie, the call does not pass up to AbstractFunction1.

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-6251?orig=1 Reporter: Adam Klein (aklein-at-novus.com) Affected Versions: 2.10.0 Attachments:

• call_tree.png (created on Aug 16, 2012 4:38:16 PM UTC, 125655 bytes)

[scabug]

@non said: I think this probably relates to an issue I've known about for a long time: anonymous functions defined in (specialized) generic scope don't end up being specialized properly in many (all?) cases.

Another one for the queue...