Aladdin - Scala Bugtracking
[#214] project: compiler priority: high category: bug
submitter assigned to status date submitted
Philippe Burak fixed 2003-11-04 09:40:01.0
subject ill typed code generated by transmatch
code 
class Foo {
  def foo: Int = 42;
  def bar(x: Any): Int = x match {
    case foo: Foo => foo.foo;
  }
}
what happened 
[[Trees after phase transmatch]]
// Scala source: tmp/test.scala
class Foo() extends scala.Object() {
  def foo(): scala.Int = 42;
  def bar(x: scala.Any): scala.Int = {
    val temp$0: scala.Any = x;
    var $result$0: scala.Int = 0;
    if (if (temp$0.isInstanceOf[Foo]())
      {
        val temp$1: Foo = temp$0.asInstanceOf[Foo]();
        val foo: Foo = temp$0;
        $result$0 = foo.foo();
        true
      }
    else
       false)
      $result$0
    else
       scala.MatchError.fail[scala.Int]("tmp/test.scala", 3)
  }
};
what expected

The line val foo: Foo = temp$0; is ill typed because foo has type Foo and temp$0 has type Any. There is either a missing asInstanceOf or maybe temp$0 should in fact be temp$1 which contains the same value and has the right static type.

[back to overview]
Changes of this bug report
Matthias  edited on  2003-11-04 10:01:41.0
This is related to Buraks last changes in the parser, I guess. Here, the pattern foo: Foo is translated to (foo@_):Foo. At least my pattern matcher cannot handle this ill-formed pattern. In our spec we clearly say that a typed pattern has the form x : T and there is no possibility to have something more complex in front of the colon. Therefore I suggest that we remove this translation from x to x@_, since this identity obviously leads to patterns that are not well-formed anymore.
Burak  edited on  2003-11-04 10:45:09.0

Well, a typed pattern foo:Foo clearly corresponds to foo @ (_:Foo). I though I ensured that the translation takes care of this, it seems that I forgot something. In any case we should make this work, because there should be only one abstract syntax representation for things meaning the same like x and x@_ do.

Burak  edited on  2003-11-04 12:43:07.0
Just to underline my previous comment, here is what comes out of analyze. Hence types are correct, it is the pattern matcher which does not handle x@(_:Type) correctly 
[[Trees after phase analyze]]
// Scala source: bugf.scala
class Foo extends scala{scala}.Object{()scala#Object}(){scala#Object} {
  def foo: scala{scala.type}.Int{scala.Int} = 42{scala.Int(42)};
  def bar(x: scala{scala.type}.Any{scala.Any}): scala{scala.type}.Int{scala.Int} = x{x.type}.match{[T0,T1]((T0) => T1)T1}({
      case (foo @ (_{scala.All}) : Foo{Foo}{Foo}){Foo} => foo{foo.type}.foo{scala.Int}
    }){scala.Int}
};
Burak  edited on  2003-11-04 13:49:16.0

As suspected, it was a (tiny) error in PatternMatcher. It generated the correct type test if necessary(what is expected from the context is not a subtype of the T in exp:T), but forgot to use the casted symbol after that!

I also put in slight optimizations, no temporary variables are generated for _ nodes anymore.