Aladdin - Scala Bugtracking
[#1065] project: compiler priority: high category: bug
submitter assigned to status date submitted
Sean Adriaan fixed 2007-04-24 04:02:40.0
subject type aliases really broken
code 
object Test extends Application {
  trait AddRemove {
    type Node <: NodeImpl;
    trait NodeImpl;
    
    abstract class XXX {
      type Node;
    }
    object removing extends XXX {
      type Node = AddRemove.this.Node;
      def printNode(node: Node, f: Node => String) = Console.println(f(node))
    }
  }
  
  class Linked extends AddRemove {
    type Node = NodeI // can also directly write `class Node extends super.NodeImpl' -- doesn't change the bug
    class NodeI extends super.NodeImpl
    
    removing.printNode(new NodeI, .toString)
  }

  new Linked
}
what happened 
java.lang.NoSuchMethodError: Test$Linked$$anonfun$0.apply(LTest$AddRemove$NodeImpl;)Ljava/lang/String;
        at Test$Linked$$anonfun$0.apply(typealias_overriding.scala:19)
        at Test$AddRemove$removing$.printNode(typealias_overriding.scala:11)
        at Test$Linked.(typealias_overriding.scala:19)
...
what expected No crash. Note that we can get around the bug by writing: 
removing.printNode(new NodeI, (x: Node) => x.toString)
instead of 
removing.printNode(new NodeI, .toString)
, which becomes 
removing.printNode(new NodeI, (x: removing.Node) => x.toString)
after type inference
[back to overview]
Changes of this bug report
Adriaan  edited on  2007-04-24 09:34:10.0
(I hope you don't mind I simplified the example a little) I'm still working on this, but initial exploration indicates that bridge methods are the problem (somehow type aliases are normalised inconsistently) 
    removing.printNode(new NodeI, .toString) // inference gives (x: removing.Node) => x.toString
    // the bridge for apply in the anonymous function seems to be wrong
    //  bridge:  public final Object apply(Object x$1) --> casts its arg:(Test.AddRemove.NodeImpl)x$1
    //  actual:  public final String apply(Test.Linked.NodeI nodei)
Martin: What should `removing.Node' be as seen from Linked? I assume it should be the abstract type defined in AddRemove.
Adriaan  edited on  2007-04-24 17:21:02.0
This was caused by the Uncurry phase not fully expanding alias types. More specifically, the argument&result types of anonymous functions (Function node) weren't normalized. Presumably other combinations weren't covered either. These should now be fixed.