type error on separate compilation (pickler foiled by path dependent parent type in the presence of overloading)

[scabug]

scalac shows a type error when dao.scala is compiled separately from tables.scala, but not when both are compiled together. The Slick-Play sample app is affected by this.

Also see same bug at sbt issue tracker sbt/sbt#786 .

reproduce code

// tables.scala
trait H2Driver{
    abstract class Table[T]
}

object Config {
  val driver : H2Driver = null
  def driver(app: Any): H2Driver = null
}

class Sites extends Config.driver.Table[String]

// dao.scala
class DAOBase[E]{
  type TableType <: Config.driver.Table[E]
}
class SitesDAO extends DAOBase[String]{
  type TableType = Sites
}

expected

$ scalac -cp . dao.scala tables.scala 
$ scalac -cp . dao.scala
$

actual

$ scalac . dao.scala tables.scala 
$ scalac . dao.scala

dao.scala:5: error: overriding type TableType in class DAOBase with bounds <: Config.driver.Table[String];
 type TableType has incompatible type
  type TableType = Sites
       ^
one error found
$

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-7596?orig=1
Reporter: @cvogt
Affected Versions: 2.9.3, 2.10.1, 2.10.3-RC1, 2.11.0-M3

[scabug]

@gkossakowski said:
Hi Chris,

Is there any chance to get a reproduction without external dependencies? To track down that issue we'll most likely need to minimize it further. If we get minimal reproduction there are much higher chances to fix it sooner than later.

[scabug]

@gkossakowski said:
I cannot track in JIRA who assigned me to this ticket. I'm unassigning it from myself as I don't have time to work on it at the moment.

My previous comment is still valid: we need a minimal test case without external dependencies.

[scabug]

@cvogt said:
Greg, I tried to remove the dependency without immediate success. I'll give it another shot at removing the dependency and report back.

Don't you think a fix for this should ideally go into 2.10.3 ?

[scabug]

@gkossakowski said:
Scala team is shifting focus to master as our deadlines are tight and resources very constrained.

We will be fixing only blocker bugs. We consider blockers to be regressions or serious malfunction without any feasible work-around available. We can determine whether this is blocker according to that definition once we have minimal test case which will help us to understand the problem.

[scabug]

@cvogt said:
Here we go, I eliminated the dependency and managed to condense it further.

[scabug]

@cvogt said (edited on Jun 19, 2013 7:43:44 PM UTC):
The issue exists in 2.9.3 (adapted the code sample to compile there). So it is not a regression.

The workaround would be forcing re-compilation of all related files. Or simply running clean before compilation after each time you modify dao.scala . In Play! (where I encountered it) this means stopping the server, running clean, restarting, recompiling everything. Not sure you can call this feasible :). Is there a better workaround?

[scabug]

@retronym said (edited on Jun 19, 2013 7:50:59 PM UTC):
I'm taking a quick look to characterize the problem. Thanks for the small repro.

[scabug]

@gkossakowski said:
Chris,

Thanks for taking time to minimize it further. This makes our job a lot easier!

[scabug]

@retronym said (edited on Jun 19, 2013 8:13:07 PM UTC):
Here's a slightly reduced test case:

https://github.com/retronym/scala/compare/ticket/7596?expand=1

Within that patch, see pos/t7596c for a workaround. Any variation of that will work so long as the prefix for the path dependent types doesn't share a name with overloaded methods.

[scabug]

@retronym said:
I guess "exposure to bugs in the compiler" would make it into my answer to "Why avoid method overloading" on SO. http://stackoverflow.com/a/2512001/160378 :)

[scabug]

@retronym said:
scala/scala#2664

[scabug]

@cvogt said:
So if you control the code, a viable workaround would be avoiding overloading. But the overloaded methods could come from a library, in which case as a user you have to fall back to clean/recompilation as described above. (Or submit a PR against the library like playframework/play-slick#53).

[scabug]

@cvogt said:
Jason, I added a link to this issue as a comment to your stackoverflow answer.

[scabug]

@adriaanm said:
Unassigning and rescheduling to M6 as previous deadline was missed.