Scala Programming Language
  1. Scala Programming Language
  2. SI-5500

Strange type error with some AnyRef specializations (but not others)

    Details

      Description

      I think this might be related to some of the issues uncovered in SI-5488.

      The basic gist is that while AnyRef specialization is working for simple type combinations (e.g. @specialized(Int, AnyRef) it seems to be breaking for "full specialization". Here's the code:

      import scala.{specialized => spec}
      
      // specialized on Int/AnyRef only
      class C1[@spec(Int, AnyRef) A, @spec(Int, AnyRef) B](v:A, w:B)
      
      // specialized on everything
      class C2[@spec(Unit, Boolean, Byte, Char, Short, Int, Long, Float, Double, AnyRef) A, @spec(Unit, Boolean, Byte, Char, Short, Int, Long, Float, Double, AnyRef) B](v:A, w:B)
      
      // specialized on everything except AnyRef
      class C3[@spec(Unit, Boolean, Byte, Char, Short, Int, Long, Float, Double) A, @spec(Unit, Boolean, Byte, Char, Short, Int, Long, Float, Double) B](v:A, w:B)
      
      object Test {
        def main(args:Array[String]) {
          // as expected, this specializes properly to C1$mcLI$sp
          println(new C1("abc", 123).getClass.getName)
      
          // this tries to use C2$mcLI$sp but fails to compile due to a bug
          println(new C2("abc", 123).getClass.getName)
          //test.scala:18: error: type mismatch;
          // found   : String("abc")
          // required: A$sp
          //    println(new C3("abc", 123).getClass.getName) // explodes
          //            ^
          //one error found
      
          // as expected, this uses the generic C3
          println(new C3("abc", 123).getClass.getName)
        }
      }
      

      Commenting out the second println allows the whole thing to compile and run as expected.

      This error crops up when substituting C2$mcLI$sp for C2 in the tree, and the typing the new tree. I'm not sure why it works for C1 but not for C2. The trees look the same, at least as far as I can tell (e.g. using log output). Probably I need to figure out how to hook up a debugger and take a closer look.

        Activity

        Hide
        Paul Phillips added a comment -

        1df4fc6e59 and ec160bae7e

        Show
        Paul Phillips added a comment - 1df4fc6e59 and ec160bae7e
        Hide
        Jason Zaugg added a comment -

        > Do you have any advice for running scalac in a debugger?

        > Ha ha, I've never done it.

        I find it useful, and pretty straightforward. Maybe it can trim an hour or two from your efforts. Here's a guide I prepared: Debugging Scalac in five minutes flat:

        https://gist.github.com/863884

        You can do something similar with an IntelliJ project based on the checked-out sources of scala; in that case I tend to add -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005 to JAVA_OPTS before running scalac, then connect to it with a Remote Debug configuration.

        http://www.jetbrains.com/idea/webhelp/run-debug-configuration-remote.html

        Of course the biggest time saver is to whittle down a five line reproduction before diving into the compiler internals, but I think you've already internalized this life skill.

        Show
        Jason Zaugg added a comment - > Do you have any advice for running scalac in a debugger? > Ha ha, I've never done it. I find it useful, and pretty straightforward. Maybe it can trim an hour or two from your efforts. Here's a guide I prepared: Debugging Scalac in five minutes flat: https://gist.github.com/863884 You can do something similar with an IntelliJ project based on the checked-out sources of scala; in that case I tend to add -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005 to JAVA_OPTS before running scalac , then connect to it with a Remote Debug configuration. http://www.jetbrains.com/idea/webhelp/run-debug-configuration-remote.html Of course the biggest time saver is to whittle down a five line reproduction before diving into the compiler internals, but I think you've already internalized this life skill.
        Hide
        Jason Zaugg added a comment -

        As an aside, this reminds me of tracking down a similar over-optimistic caching problem with implicits way back when. Now that all the caches are centralized in `perRunCaches`, it might be feasible to add `-Ycache-disable` as a generic troubleshooting option.

        Show
        Jason Zaugg added a comment - As an aside, this reminds me of tracking down a similar over-optimistic caching problem with implicits way back when. Now that all the caches are centralized in `perRunCaches`, it might be feasible to add `-Ycache-disable` as a generic troubleshooting option.
        Hide
        Paul Phillips added a comment -

        Most of the maps created via perRunCaches are not performance optimizations, they are necessary for correctness. They're typically of the form "I need to find this thing later and do one more thing to it after some other thing has happened." The "per-run" aspect is to protect the resident compiler from leaks they may/do contain.

        Show
        Paul Phillips added a comment - Most of the maps created via perRunCaches are not performance optimizations, they are necessary for correctness. They're typically of the form "I need to find this thing later and do one more thing to it after some other thing has happened." The "per-run" aspect is to protect the resident compiler from leaks they may/do contain.
        Hide
        Jason Zaugg added a comment -

        Ah, good to know. Thanks for the explanation.

        Show
        Jason Zaugg added a comment - Ah, good to know. Thanks for the explanation.

          People

          • Assignee:
            Paul Phillips
            Reporter:
            Erik Osheim
          • Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development