Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
scabug opened this issue Jun 19, 2013 · 18 comments

Comments

@scabug
Copy link

scabug commented Jun 19, 2013

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
Copy link
Author

scabug commented Jun 19, 2013

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
Copy link
Author

scabug commented Jun 19, 2013

@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
Copy link
Author

scabug commented Jun 19, 2013

@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
Copy link
Author

scabug commented Jun 19, 2013

@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
Copy link
Author

scabug commented Jun 19, 2013

@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
Copy link
Author

scabug commented Jun 19, 2013

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

@scabug
Copy link
Author

scabug commented Jun 19, 2013

@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
Copy link
Author

scabug commented Jun 19, 2013

@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
Copy link
Author

scabug commented Jun 19, 2013

@gkossakowski said:
Chris,

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

@scabug
Copy link
Author

scabug commented Jun 19, 2013

@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
Copy link
Author

scabug commented Jun 19, 2013

@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
Copy link
Author

scabug commented Jun 19, 2013

@retronym said:
scala/scala#2664

@scabug
Copy link
Author

scabug commented Jun 21, 2013

@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
Copy link
Author

scabug commented Jun 21, 2013

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

@scabug
Copy link
Author

scabug commented Jul 10, 2013

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

@scabug
Copy link
Author

scabug commented Aug 5, 2014

@gkossakowski said:
The 2.11.2 is out so I'm rescheduling the issue for 2.11.3.

@scabug
Copy link
Author

scabug commented Nov 4, 2014

@retronym said:
Updating fix-by version to 2.11.5.

@scabug
Copy link
Author

scabug commented Nov 6, 2014

@retronym said:
scala/scala#4099

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants