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

Illegal cyclic reference regression in 2.13 #11734

Open
ybasket opened this issue Sep 12, 2019 · 6 comments
Open

Illegal cyclic reference regression in 2.13 #11734

ybasket opened this issue Sep 12, 2019 · 6 comments
Milestone

Comments

@ybasket
Copy link

ybasket commented Sep 12, 2019

In typelevel/squants#344 we face the following problem when compiling with 2.13 (2.10-2.12 work fine) - blocking squants to be released for 2.13:

[error] squants/shared/src/main/scala/squants/motion/Acceleration.scala:25:25: illegal cyclic reference involving class Velocity
[error]     with TimeDerivative[Velocity]

Some work fixing such issues was already done in #11640, but even the integration builds of the compiler containing the fix (I used now 2.13.1-bin-d602ff4) still fail to compile squants. If I add -Ybreak-cycles -Yrecursion 2147483647 compiler flags the error message changes a bit:

[error] squants/shared/src/main/scala/squants/motion/Velocity.scala:24:13: self constructor arguments cannot reference unconstructed `this`
[error]     extends Quantity[Velocity]

Extracting a minimal example has not worked so far, even when extracting larger parts of the class hierarchy, so I can't provide more than a branch of squants to test for now: https://github.com/ybasket/squants/tree/scala-2.13

One possibility to investigate might be the alternative solution to #11640 proposed by @adriaanm in #11640 (comment).

Let me know if any more details are needed or there are things to be tried.

@ybasket
Copy link
Author

ybasket commented Nov 27, 2019

I was able to find a work around for squants and by that got more insights on this bug. It seems to be related to the wildcard import of type aliases defined in the squants package object which shadow the fact that the classes referencing each other as type arguments to parent classes are in the same package. Apparently scalac gives up on resolving this cycle through the type aliases though the cycles are actually compilable when defined without aliases (or as-is on 2.11/2.12).

I pushed a minimal working example to https://github.com/ybasket/squants-compiler-bug-example – happy to help if I can.

@SethTisue
Copy link
Member

SethTisue commented Nov 27, 2019

It seems to be related to the wildcard import of type aliases

I wonder if scala/scala#6589 (see also #11593) is an ingredient in this mix. Does it seem relevant to you? (I haven't looked at your example code, apologies in advance if the question is off-base.)

@ybasket
Copy link
Author

ybasket commented Nov 28, 2019

I wonder if scala/scala#6589 (see also #11593) is an ingredient in this mix. Does it seem relevant to you? (I haven't looked at your example code, apologies in advance if the question is off-base.)

Seems quite relevant.

So it might even be a desired breaking change in the Scala compiler causing it. I wonder whether in this case the cycle resolving logic should be updated to also work "through" type aliases. But my knowledge of the spec and the possibilities to implement such behaviour ends here, so I have to leave this discussion to more informed people.

@Facsimiler
Copy link

I'm not sure whether it's related to the OP's issue, but I get this same error in a very simple case (that didn't cause an error in Scala 2.12) using Scala 2.13.1:

class X {
  // ...
  class Y extends Ordered[X#Y] { // <- Illegal cyclic reference involving class Y
    // ...
  }
}

I can't see any reason why this should be illegal code, but I'm certainly willing to hear an explanation...

@SethTisue
Copy link
Member

fwiw, Dotty accepts @Facsimiler's code:

scala> class X { class Y extends Ordered[X#Y] { def compare(that: X#Y) = ??? } }
// defined class X

@SethTisue SethTisue modified the milestones: 2.13.2, 2.13.3 Feb 6, 2020
@markusa380
Copy link

I'm experiencing this issue too, restructuring the packages solved it for me.

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

5 participants