Details

      Description

      This code fails at runtime:

      scala> class A(val p: Int*); case class B(p1: Int) extends A(p1); new B(1)
      java.lang.ClassCastException: scala.collection.mutable.WrappedArray$ofInt cannot be cast to java.lang.Integer
      

      The error only occurs in combination of a case class extending a class taking a vararg ctor that is marked as val.

      Looking at the generated code the bug is obvious:

      def p1(): Int = scala.Int.unbox(Main$$anon$1$B.super.p());
      

      and

      def <init>($outer: anonymous class anon$1, p1: Int): anonymous class anon$1$B = {
            Main$$anon$1$B.super.<init>($outer, scala.this.Predef.wrapIntArray(Array[Int]{p1}));
            scala.Product$class./*Product$class*/$init$(Main$$anon$1$B.this);
            ()
          }
        };
      
      

      p1 is not correctly set in the ctor of B. Instead it treats p as the same value and tries to get the value from it.

        Issue Links

          Activity

          Hide
          Adam Retter added a comment -

          It seems to be that this is a regression, as this works in Scala 2.10.0, however it does not work in any newer bugfix 2.10 version (i.e. 2.10.1, 2.10.2, 2.10.3 and 2.10.4-RC2). I believe that as this works in 2.10.0, it should work in all 2.10.x versions.

          My test case is not as elegant as the one initially posted, but for completeness, here it is:

          object Blah extends App {
          
            trait ArgProvider {
            }
          
            case class ColumnReference(value: String) extends ArgProvider
          
          
            abstract class Rule(name: String, val argProviders: ArgProvider*)
          
            case class InRule(inValue: ArgProvider) extends Rule("in", inValue) {
          
              def valid(): Boolean = {
                println(inValue.getClass) //This causes a ClassCastException on 2.10.1+ but not 2.10.0
          
                true
              }
            }
          
            val rule = InRule(ColumnReference("Column1"))
            rule.valid()
          }
          

          I have been suggested the workaround of defining the `InRule` class as:

          case class InRule(inValue: ArgProvider) extends Rule("in", Seq(inValue): _*) {
            ...
          }
          

          Whilst the workaround helps me, I still have to modify my code to move onward from 2.10.0 to 2.10.1+ which is not ideal.

          Show
          Adam Retter added a comment - It seems to be that this is a regression, as this works in Scala 2.10.0, however it does not work in any newer bugfix 2.10 version (i.e. 2.10.1, 2.10.2, 2.10.3 and 2.10.4-RC2). I believe that as this works in 2.10.0, it should work in all 2.10.x versions. My test case is not as elegant as the one initially posted, but for completeness, here it is: object Blah extends App { trait ArgProvider { } case class ColumnReference(value: String) extends ArgProvider abstract class Rule(name: String, val argProviders: ArgProvider*) case class InRule(inValue: ArgProvider) extends Rule("in", inValue) { def valid(): Boolean = { println(inValue.getClass) //This causes a ClassCastException on 2.10.1+ but not 2.10.0 true } } val rule = InRule(ColumnReference("Column1")) rule.valid() } I have been suggested the workaround of defining the `InRule` class as: case class InRule(inValue: ArgProvider) extends Rule("in", Seq(inValue): _*) { ... } Whilst the workaround helps me, I still have to modify my code to move onward from 2.10.0 to 2.10.1+ which is not ideal.
          Hide
          Adam Retter added a comment -

          I really believe this is a regression in 2.10.1+, as it works fine in 2.10.0. If I understand your semantic versioning scheme then bugfix releases should not introduce breaking changes, so I am classing this as a regression.

          It is nice to know it is fixed in the upcoming 2.11, but not everyone has the luxury of being able to easily move to 2.11, especially when there is not yet a stable version.

          Show
          Adam Retter added a comment - I really believe this is a regression in 2.10.1+, as it works fine in 2.10.0. If I understand your semantic versioning scheme then bugfix releases should not introduce breaking changes, so I am classing this as a regression. It is nice to know it is fixed in the upcoming 2.11, but not everyone has the luxury of being able to easily move to 2.11, especially when there is not yet a stable version.
          Hide
          Adriaan Moors added a comment -

          Fixed on 2.11.0-M4 (since it's a fix-version in the past), fix pending for 2.10.5-RC1.

          Show
          Adriaan Moors added a comment - Fixed on 2.11.0-M4 (since it's a fix-version in the past), fix pending for 2.10.5-RC1.
          Hide
          Adriaan Moors added a comment -

          Sorry about the regression, Adam. Scheduled for a fix in 2.10.5-RC1.

          Show
          Adriaan Moors added a comment - Sorry about the regression, Adam. Scheduled for a fix in 2.10.5-RC1.
          Hide
          Adam Retter added a comment -

          No worries Adriaan, we only just hit it in the last couple months. I just wanted to bump the Jira issue, in the hope it would get resolved. Thanks for looking into it.

          Show
          Adam Retter added a comment - No worries Adriaan, we only just hit it in the last couple months. I just wanted to bump the Jira issue, in the hope it would get resolved. Thanks for looking into it.

            People

            • Assignee:
              Jason Zaugg
              Reporter:
              Simon Schäfer
            • Votes:
              2 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated:

                Development