Details

      Description

      Compiles in 2.9.2, not in 2.10.0.

      trait HK {
        type Rep[A]
        def unzip1[A, B, C[_]](ps: Rep[C[(A, B)]]): (Rep[C[A]], Rep[C[B]])
        def doUnzip1[A, B](ps: Rep[List[(A, B)]]) = unzip1(ps)
      }
      
      ./a.scala:7: error: type mismatch;
       found   : HK.this.Rep[List[(A, B(in method doUnzip1))]]
       required: HK.this.Rep[List[((A, B(in method doUnzip1)), B(in method unzip1))]]
        def doUnzip1[A, B](ps: Rep[List[(A, B)]]) = unzip1(ps)
                                                           ^
      one error found
      

      The commit in which it regressed is https://github.com/scala/scala/commit/0cde930b19 ; I don't yet see how.

        Issue Links

          Activity

          Hide
          Jason Zaugg added a comment -

          Some variations:

          trait HK {
            type Rep[X]
          
            // okay
            def unzip2[A, B](ps: Rep[List[(A, B)]])
            unzip2(null.asInstanceOf[Rep[List[(Int, String)]]])
          
            // okay
            def unzipHK[A, B, C[_]](ps: Rep[C[(A, B)]])
            unzipHK(null.asInstanceOf[Rep[List[(Int, String)]]])
          
            // fail
            def unzipHKRet[A, B, C[_]](ps: Rep[C[(A, B)]]): (Rep[C[A]], Rep[C[B]])
            unzipHKRet(null.asInstanceOf[Rep[List[(Int, String)]]])
          }
          
          Show
          Jason Zaugg added a comment - Some variations: trait HK { type Rep[X] // okay def unzip2[A, B](ps: Rep[List[(A, B)]]) unzip2(null.asInstanceOf[Rep[List[(Int, String)]]]) // okay def unzipHK[A, B, C[_]](ps: Rep[C[(A, B)]]) unzipHK(null.asInstanceOf[Rep[List[(Int, String)]]]) // fail def unzipHKRet[A, B, C[_]](ps: Rep[C[(A, B)]]): (Rep[C[A]], Rep[C[B]]) unzipHKRet(null.asInstanceOf[Rep[List[(Int, String)]]]) }
          Hide
          Adriaan Moors added a comment -

          As alluded by Jason's okay<>fail/unzipHK<>unzipHKRet, it looks like unzip1's return type is driving inference:

          defining (note the existentials in the return type)

            def unzip1[A, B, C[_]](ps: Rep[C[(A, B)]]): (Rep[C[_]], Rep[C[_]])
          

          results in the inferred:

              def doUnzip1[T1 >: Nothing <: Any, T2 >: Nothing <: Any](ps: HK.this.Rep[List[(T1, T2)]]): (HK.this.Rep[List[_]], HK.this.Rep[List[_]]) = HK.this.unzip1[T1, T2, List](ps)
          
          Show
          Adriaan Moors added a comment - As alluded by Jason's okay<>fail/unzipHK<>unzipHKRet, it looks like unzip1's return type is driving inference: defining (note the existentials in the return type) def unzip1[A, B, C[_]](ps: Rep[C[(A, B)]]): (Rep[C[_]], Rep[C[_]]) results in the inferred: def doUnzip1[T1 >: Nothing <: Any, T2 >: Nothing <: Any](ps: HK.this.Rep[List[(T1, T2)]]): (HK.this.Rep[List[_]], HK.this.Rep[List[_]]) = HK.this.unzip1[T1, T2, List](ps)
          Hide
          Paul Phillips added a comment - - edited

          Before the commit in question:

          % ./working/bin/scalac -Yinfer-debug -d /tmp /scala/trunk/test/files/pos/t7226.scala 
          [solve types] solving for A, B, C in ?A, ?B, ?C
          [infer method] solving for A, B, C in (ps: HK.this.Rep[C[(A, B)]])(HK.this.Rep[C[A]], HK.this.Rep[C[B]])
            based on (HK.this.Rep[List[(T1, T2)]])(HK.this.Rep[C[A]], HK.this.Rep[C[B]])
            (solved: A=T1, B=T2, C=List)
          

          After:

          % scalac3 -Yinfer-debug -d /tmp /scala/trunk/test/files/pos/t7226.scala 
          [solve types] solving for A, B, C in ?A, ?B, ?C
          [infer method] solving for A, B, C in (ps: HK.this.Rep[C[(A, B)]])(HK.this.Rep[C[A]], HK.this.Rep[C[B]])
            based on (HK.this.Rep[List[(T1, T2)]])(HK.this.Rep[C[A]], HK.this.Rep[C[B]])
            (solved: A=(T1, T2), C=List)
          
          Show
          Paul Phillips added a comment - - edited Before the commit in question: % ./working/bin/scalac -Yinfer-debug -d /tmp /scala/trunk/test/files/pos/t7226.scala [solve types] solving for A, B, C in ?A, ?B, ?C [infer method] solving for A, B, C in (ps: HK.this.Rep[C[(A, B)]])(HK.this.Rep[C[A]], HK.this.Rep[C[B]]) based on (HK.this.Rep[List[(T1, T2)]])(HK.this.Rep[C[A]], HK.this.Rep[C[B]]) (solved: A=T1, B=T2, C=List) After: % scalac3 -Yinfer-debug -d /tmp /scala/trunk/test/files/pos/t7226.scala [solve types] solving for A, B, C in ?A, ?B, ?C [infer method] solving for A, B, C in (ps: HK.this.Rep[C[(A, B)]])(HK.this.Rep[C[A]], HK.this.Rep[C[B]]) based on (HK.this.Rep[List[(T1, T2)]])(HK.this.Rep[C[A]], HK.this.Rep[C[B]]) (solved: A=(T1, T2), C=List)
          Hide
          Jason Zaugg added a comment -

          The bug stems from making (the mutable) TypeVar a case class. Seems a pretty serious regression, I'd consider this for 2.10.1.

          Show
          Jason Zaugg added a comment - The bug stems from making (the mutable) TypeVar a case class. Seems a pretty serious regression, I'd consider this for 2.10.1.
          Show
          Jason Zaugg added a comment - https://github.com/scala/scala/pull/2220
          Hide
          Paul Phillips added a comment -

          Oh, because it picked up case class equality. Shoot, I didn't think of that.

          I believe 2.10.2 is the earliest which can be considered. This has been in there 7 months, and it's in 2.10.0 - and it's not a risk-free fix.

          Show
          Paul Phillips added a comment - Oh, because it picked up case class equality. Shoot, I didn't think of that. I believe 2.10.2 is the earliest which can be considered. This has been in there 7 months, and it's in 2.10.0 - and it's not a risk-free fix.
          Show
          Adriaan Moors added a comment - https://github.com/scala/scala/pull/2226

            People

            • Assignee:
              Jason Zaugg
              Reporter:
              Paul Phillips
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development