Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Type alias in package object causes type checker assertion failure #6084

Closed
scabug opened this issue Jul 14, 2012 · 8 comments
Closed

Type alias in package object causes type checker assertion failure #6084

scabug opened this issue Jul 14, 2012 · 8 comments

Comments

@scabug
Copy link

scabug commented Jul 14, 2012

The program below causes a crash, apparently due to the type alias in the package object. The commented out version compiles without a crash. See the attachment for the stack trace.

Code similar to this has been present in our Kiama library for quite a while and has compiled fine with the 2.9 series compilers.

// This version crashes the compiler:

package object foo {

    type ==>[T,U] = PartialFunction[T,U]

}

package foo {

    abstract class Foo[T,U] (val f : T ==> U) extends (T ==> U) {

        def bar (r : T ==> U) : T ==> U = 
            r match {
                case d : Foo[_, _] => d.f
                case _             => r
            }

    }

}

// This version compiles with no crashes:

// package foo {

//     abstract class Foo[T,U] (val f : PartialFunction[T,U]) extends (PartialFunction[T,U]) {

//         def bar (r : PartialFunction[T,U]) : PartialFunction[T,U] = 
//             r match {
//                 case d : Foo[_, _] => d.f
//                 case _             => r
//             }

//     }

// }
@scabug
Copy link
Author

scabug commented Jul 14, 2012

Imported From: https://issues.scala-lang.org/browse/SI-6084?orig=1
Reporter: Tony Sloane (asloane)
Affected Versions: 2.10.0-M5
Attachments:

  • trace.txt (created on Jul 14, 2012 4:33:17 PM UTC, 15345 bytes)

@scabug
Copy link
Author

scabug commented Jul 14, 2012

@paulp said:
Someone elaborated:

package object foo { type X[T, U] = (T => U) }

package foo {
  abstract class Foo[T, U](val d: T => U) extends (T => U) {
    def f1(r: X[T, U])           = r match { case x: Foo[_,_] => x.d }  // inferred ok
    def f2(r: X[T, U]): (T => U) = r match { case x: Foo[_,_] => x.d }  // dealiased ok
    def f3(r: X[T, U]): X[T, U]  = r match { case x: Foo[_,_] => x.d }  // alias not ok

    // x.d : foo.this.package.type.X[?scala.reflect.internal.Types$NoPrefix$?.T, ?scala.reflect.internal.Types$NoPrefix$?.U] ~>scala.this.Function1[?scala.reflect.internal.Types$NoPrefix$?.T, ?scala.reflect.internal.Types$NoPrefix$?.U]
    //  at scala.Predef$.assert(Predef.scala:170)
    //  at scala.tools.nsc.Global.assert(Global.scala:235)
    //  at scala.tools.nsc.ast.TreeGen.mkCast(TreeGen.scala:252)
    //  at scala.tools.nsc.typechecker.Typers$Typer.typedCase(Typers.scala:2263)
  }
}

@scabug
Copy link
Author

scabug commented Jul 30, 2012

Tony Sloane (asloane) said:
This regression is still present in 2.10.0-M6.

@scabug
Copy link
Author

scabug commented Jul 30, 2012

@retronym said:
Paul, the umbrella mkCast you added in 214c145 didn't quite fit this spot: scala/scala@214c145#L11L1916

@scabug
Copy link
Author

scabug commented Jul 30, 2012

@retronym said:
Marking as critical to get it into contention for 2.10: it's a regression and the fix looks trivial.

@scabug
Copy link
Author

scabug commented Jul 30, 2012

@paulp said:
That's the right spot, although it seems like my real problem was believing the comment ("no need for pt.normalize here")

@scabug
Copy link
Author

scabug commented Jul 30, 2012

@paulp said:
scala/scala#1023

@scabug scabug closed this as completed Aug 4, 2012
@scabug
Copy link
Author

scabug commented Aug 23, 2012

Tony Sloane (asloane) said:
To close the loop here, I can confirm that this problem does not occur in Kiama when building with 2.10.0-M7.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants