Details

      Description

      Caused by me in 9e101a3de8 .

      % scala-hash 9e101a3de8
      
      scala> val v: java.util.Vector[String] = new java.util.Vector[String](5)
      v: java.util.Vector[String] = []
      
      scala> val v: java.util.Vector[String] = new java.util.Vector[String](5)
      <console>:7: error: type mismatch;
       found   : Int(5)
       required: java.util.Collection[_ <: String]
             val v: java.util.Vector[String] = new java.util.Vector[String](5)
                                                                            ^
      

        Issue Links

          Activity

          Hide
          Jason Zaugg added a comment -

          Using ArrayList rather than Vector (which is only generic in Java 7+).

          import scala.tools.partest.ReplTest
          
          object Test extends ReplTest {
            override def code = """
            val v: java.util.ArrayList[String] = new java.util.ArrayList[String](5)
            val v: java.util.ArrayList[String] = new java.util.ArrayList[String](5)
            """
          }
          

          On the compilation of the second line, the symbol for the constructor [E](Int)ArrayList[E] has a corrupt info.

          // unwanted existential!
          TypeHistory(typer:7,(x$1: Int)java.util.ArrayList[_],null)
          // an overloaded constuctor
          TypeHistory(posterasure:5,(x$1: java.util.Collection)java.util.ArrayList,TypeHistory(namer:7,(x$1: java.util.Collection[_ <: E])java.util.ArrayList[E],null))
          

          Overload resolution discounts the Int-accepting constructor, and ends up reporting "found: Int, required: Collection".

          Here's a symptomatic fix:

          https://github.com/retronym/scala/compare/ticket/7482

          I'm going to look a bit harder for the underlying problem, but if I can't find it, I think we should go with this fix for 2.11.0-M3. `modifyInfoConserve` might still make sense on performance grounds.

          Show
          Jason Zaugg added a comment - Using ArrayList rather than Vector (which is only generic in Java 7+). import scala.tools.partest.ReplTest object Test extends ReplTest { override def code = """ val v: java.util.ArrayList[String] = new java.util.ArrayList[String](5) val v: java.util.ArrayList[String] = new java.util.ArrayList[String](5) """ } On the compilation of the second line, the symbol for the constructor [E] (Int)ArrayList [E] has a corrupt info. // unwanted existential! TypeHistory(typer:7,(x$1: Int)java.util.ArrayList[_],null) // an overloaded constuctor TypeHistory(posterasure:5,(x$1: java.util.Collection)java.util.ArrayList,TypeHistory(namer:7,(x$1: java.util.Collection[_ <: E])java.util.ArrayList[E],null)) Overload resolution discounts the Int-accepting constructor, and ends up reporting "found: Int, required: Collection". Here's a symptomatic fix: https://github.com/retronym/scala/compare/ticket/7482 I'm going to look a bit harder for the underlying problem, but if I can't find it, I think we should go with this fix for 2.11.0-M3. `modifyInfoConserve` might still make sense on performance grounds.
          Hide
          Jason Zaugg added a comment -

          It seems that a call to `cookJavaRawInfo` during typechecking in erasure is responsible for the unwanted existential. It considers the erased result type of the constructor to be a raw, expands it to the existential, and then calls setInfo (via modifyInfo, which is rather a destructive thing to do, as it discards the symbols type history.

          I still can't quite trace out why the old code was immune to this effect. But I can see a few ways that we can remedy this:

          • don't cook raw types if phase.erasedTypes. This seems like a clear win to me.
          • use updateInfo rather than modifyInfo. It seems like we should treat any calls to modify/setInfo with some suspicion. Are there cases when they are necessary for correctness?
          • Change modifyInfo (or make a variant) to be a no-op if the function doesn't transform the type.
          Show
          Jason Zaugg added a comment - It seems that a call to `cookJavaRawInfo` during typechecking in erasure is responsible for the unwanted existential. It considers the erased result type of the constructor to be a raw, expands it to the existential, and then calls setInfo (via modifyInfo , which is rather a destructive thing to do, as it discards the symbols type history. I still can't quite trace out why the old code was immune to this effect. But I can see a few ways that we can remedy this: don't cook raw types if phase.erasedTypes . This seems like a clear win to me. use updateInfo rather than modifyInfo . It seems like we should treat any calls to modify/setInfo with some suspicion. Are there cases when they are necessary for correctness? Change modifyInfo (or make a variant) to be a no-op if the function doesn't transform the type.
          Hide
          Paul Phillips added a comment -

          "don't cook raw types if phase.erasedTypes. This seems like a clear win to me"

          Forget win, isn't it necessary for correctness? The raw type IS the type after erasure.

          "Change modifyInfo (or make a variant) to be a no-op if the function doesn't transform the type."

          Huh, I could swear I did that long ago. Must have died in a branch.

          Show
          Paul Phillips added a comment - "don't cook raw types if phase.erasedTypes. This seems like a clear win to me" Forget win, isn't it necessary for correctness? The raw type IS the type after erasure. "Change modifyInfo (or make a variant) to be a no-op if the function doesn't transform the type." Huh, I could swear I did that long ago. Must have died in a branch.
          Hide
          Paul Phillips added a comment -

          Also, thanks a lot for looking at it, that information will save me a ton of time whatever happens.

          Show
          Paul Phillips added a comment - Also, thanks a lot for looking at it, that information will save me a ton of time whatever happens.
          Hide
          Paul Phillips added a comment -

          37884ec

          Show
          Paul Phillips added a comment - 37884ec

            People

            • Assignee:
              Paul Phillips
              Reporter:
              Paul Phillips
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development