Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: Scala 2.10.0-M7
    • Fix Version/s: Scala 2.10.0-RC1
    • Component/s: None
    • Labels:
    • Environment:

      OS X Lion.

      Description

      def foo = {
        var a = ArrayBuffer[Int]()
        println (a.isInstanceOf[Seq[Int]])
      }
      

      gives the following warning under -checked:

      warning: non variable type-argument Int in type scala.collection.mutable.Seq[Int] is unchecked since it is eliminated by erasure
        println (a.isInstanceOf[Seq[Int]])
      

      Surely there should be no complaint about erasure in a purely local analysis. I'm telling it that it is a buffer of Int, and expect it to infer that it is a seq of Int.

        Activity

        Hide
        Jason Zaugg added a comment -

        Use a type ascription, not a cast, to achieve what you describe.

        println(a: Seq[Int])
        

        In the future, could you please first check on the [scala-language] mailing list before lodging tickets for things that are not clear bugs.

        Show
        Jason Zaugg added a comment - Use a type ascription, not a cast, to achieve what you describe. println(a: Seq[Int]) In the future, could you please first check on the [scala-language] mailing list before lodging tickets for things that are not clear bugs.
        Hide
        Sriram Srinivasan added a comment - - edited

        You could start by giving me a little credit. I know exactly how to get around the warning. The issue is not about the cast.

        The bigger issue, which affects my code everywhere is this: The variable `a` is local, and any self-respecting intra-procedural analysis should reflect that `a` is a `Seq[Int]`. It should not need any further ascription, and requiring it should be considered a bug. This should NOT be an issue of erasure.

        Show
        Sriram Srinivasan added a comment - - edited You could start by giving me a little credit. I know exactly how to get around the warning. The issue is not about the cast. The bigger issue, which affects my code everywhere is this: The variable `a` is local, and any self-respecting intra-procedural analysis should reflect that `a` is a `Seq [Int] `. It should not need any further ascription, and requiring it should be considered a bug. This should NOT be an issue of erasure.
        Hide
        Jason Zaugg added a comment -

        That's all fine, but JIRA is just so overloaded that we can't use it for these sort of discussions. "Please use the mailing list" isn't intended to be dismissive, it is just to channel your questions / suggestions to a suitable forum with a wider audience.

        Show
        Jason Zaugg added a comment - That's all fine, but JIRA is just so overloaded that we can't use it for these sort of discussions. "Please use the mailing list" isn't intended to be dismissive, it is just to channel your questions / suggestions to a suitable forum with a wider audience.
        Hide
        A. P. Marki added a comment -

        You don't have to give me any credit, if I don't get it.

        The example is isInstanceOf, not asInstanceOf.

        For the case of asInstanceOf, there is no extra checkcast. Let's give intraprocedural analysis some respect.

        For the lack of a warning, SI-1558. So on that basis, I'll never asInstanceOf, because I'll never presume to tell the type system I know what I'm doing. Except maybe null.asInstanceOf.

        For the case of isInstanceOf, maybe the question is, should instanceof be optimized away.

        If you issue the instanceof, should you still warn? And if you must warn, is there a way to selectively turn off warnings? (Hopefully eventually?)

        Show
        A. P. Marki added a comment - You don't have to give me any credit, if I don't get it. The example is isInstanceOf, not asInstanceOf. For the case of asInstanceOf, there is no extra checkcast. Let's give intraprocedural analysis some respect. For the lack of a warning, SI-1558 . So on that basis, I'll never asInstanceOf, because I'll never presume to tell the type system I know what I'm doing. Except maybe null.asInstanceOf. For the case of isInstanceOf, maybe the question is, should instanceof be optimized away. If you issue the instanceof, should you still warn? And if you must warn, is there a way to selectively turn off warnings? (Hopefully eventually?)
        Hide
        Seth Tisue added a comment -

        So Jason mistook isInstanceOf for asInstanceOf, but it doesn't matter: he's right on the larger issue, which is that this should be a mailing list discussion, not a ticket. Eventually one or more tickets might result. (And telling you this is being helpful, not issuing a reprimand.)

        Show
        Seth Tisue added a comment - So Jason mistook isInstanceOf for asInstanceOf, but it doesn't matter: he's right on the larger issue, which is that this should be a mailing list discussion, not a ticket. Eventually one or more tickets might result. (And telling you this is being helpful, not issuing a reprimand.)
        Hide
        Seth Tisue added a comment -

        there is now a thread, started by Mark Harrah, at https://groups.google.com/d/topic/scala-internals/9bT7clmkLYk/discussion

        Show
        Seth Tisue added a comment - there is now a thread, started by Mark Harrah, at https://groups.google.com/d/topic/scala-internals/9bT7clmkLYk/discussion
        Hide
        Mark Harrah added a comment -

        Reopening due to the mentioned thread and copying the example here:

        I see the following spurious warning frequently, which drowns out useful unchecked warnings:

        sealed trait A[T]
        final class B[T] extends A[T]
        
        object ParsedAxis {
           def x(a: A[Int]) =
              a match {
                 case b: B[Int] => 3
              }
        }
        
        A.scala:7: non-variable type argument Int in type pattern B[Int] is unchecked since it is eliminated by erasure
                 case b: B[Int] => 3
                         ^
        

        In this case, the warning can be resolved by using a type variable:

                 case b: B[i] => 3
        

        but this is less useful when reading the code and isn't possible when `B[Int]` is inside a type alias like `type BI = B[Int]`. Similarly, `Int @unchecked` can be used, but it is less safe than the type variable approach, where the compiler still knows that `i=Int` is the only possibility. In fact, if another type argument is used, the compiler complains:

        pattern type is incompatible with expected type;
          found   : B[String]
          required: A[Int]
                 case b: B[String] => 3
                         ^
        
        Show
        Mark Harrah added a comment - Reopening due to the mentioned thread and copying the example here: I see the following spurious warning frequently, which drowns out useful unchecked warnings: sealed trait A[T] final class B[T] extends A[T] object ParsedAxis { def x(a: A[Int]) = a match { case b: B[Int] => 3 } } A.scala:7: non-variable type argument Int in type pattern B[Int] is unchecked since it is eliminated by erasure case b: B[Int] => 3 ^ In this case, the warning can be resolved by using a type variable: case b: B[i] => 3 but this is less useful when reading the code and isn't possible when `B [Int] ` is inside a type alias like `type BI = B [Int] `. Similarly, `Int @unchecked` can be used, but it is less safe than the type variable approach, where the compiler still knows that `i=Int` is the only possibility. In fact, if another type argument is used, the compiler complains: pattern type is incompatible with expected type; found : B[String] required: A[Int] case b: B[String] => 3 ^
        Hide
        Mark Harrah added a comment -

        Copied from Paul's comment on SI-6338:

        I'm not really working on 2.10 anymore, but if anyone wants it, this warning and other issues are handled here: https://github.com/paulp/scala/tree/topic/210-quieter-warnings

        Show
        Mark Harrah added a comment - Copied from Paul's comment on SI-6338 : I'm not really working on 2.10 anymore, but if anyone wants it, this warning and other issues are handled here: https://github.com/paulp/scala/tree/topic/210-quieter-warnings

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development