Scala Programming Language
  1. Scala Programming Language
  2. SI-6535

"extends AnyRef" should not induce cyclic reference errors

    Details

      Description

      30 errors is a lot of errors for something which should be a no-op. It's supposed to mean "extends AnyRef" already!

      # 2.10.0-RC1, compiles
      % scalac src/library/scala/collection/convert/Wrap*.scala 
      # add 'extends AnyRef' to WrapAsScala
      % git diff
      -trait WrapAsScala extends LowPriorityWrapAsScala {
      +trait WrapAsScala extends AnyRef with LowPriorityWrapAsScala {
      
      % scalac src/library/scala/collection/convert/Wrap*.scala
      src/library/scala/collection/convert/WrapAsScala.scala:13: error: illegal cyclic reference involving object Wrappers
      import Wrappers._
             ^
      [snip]
      30 errors found.
      

        Activity

        Hide
        Jason Zaugg added a comment - - edited

        Minimization: https://github.com/retronym/scala/compare/scala:2.10.x...retronym:ticket/6535

        object As {
          import Bs.B._
        
          object A
          extends scala.Immutable // needed for the cycle; scala.{Serializable, Clonable} also work.
                                  // replacing with a locally defined closs doesn't cycle.
        }
        
        object Bs {
          import As.A._
        
          object B
          extends AnyRef // or scala.Immutable / whatever...
        }
        
        
        Show
        Jason Zaugg added a comment - - edited Minimization: https://github.com/retronym/scala/compare/scala:2.10.x...retronym:ticket/6535 object As { import Bs.B._ object A extends scala.Immutable // needed for the cycle; scala.{Serializable, Clonable} also work. // replacing with a locally defined closs doesn't cycle. } object Bs { import As.A._ object B extends AnyRef // or scala.Immutable / whatever... }
        Hide
        Jason Zaugg added a comment -

        @Paul: I'll continue with this one tomorrow. If you've got any tips for chasing cycles, I'm all ears.

        Show
        Jason Zaugg added a comment - @Paul: I'll continue with this one tomorrow. If you've got any tips for chasing cycles, I'm all ears.
        Hide
        Paul Phillips added a comment -

        They're all prayer related, but it'd be interesting to look at cycles simultaneously.

        Show
        Paul Phillips added a comment - They're all prayer related, but it'd be interesting to look at cycles simultaneously.
        Hide
        Jason Zaugg added a comment -

        https://github.com/scala/scala/pull/1700

        I believe the cycle was valid: although adding scala.AnyRef as a parent is a no-op, determining that "AnyRef" binds to said class requires interrogation of enclosing imports, which is enough to expose the cycle.

        I added a neg test case to show the situation, and also rearranged the imports to avoid flying so close to the sun.

        Show
        Jason Zaugg added a comment - https://github.com/scala/scala/pull/1700 I believe the cycle was valid: although adding scala.AnyRef as a parent is a no-op, determining that "AnyRef" binds to said class requires interrogation of enclosing imports, which is enough to expose the cycle. I added a neg test case to show the situation, and also rearranged the imports to avoid flying so close to the sun.
        Hide
        Paul Phillips added a comment -

        Entering code block in anticipation of my underscores becoming italics...

        Would you agree that it's a bug that it fails even if I fully qualify everything with _root_,
        e.g. _root_.scala.AnyRef? We have already established in other tickets that _root_ is barely
        acknowledged internally; you can define a package named _root_, etc. But if _root_ were
        handled like the reserved word that it should be, then a parent _root_.scala.AnyRef should
        not require any enhanced interrogation.
        
        Show
        Paul Phillips added a comment - Entering code block in anticipation of my underscores becoming italics... Would you agree that it's a bug that it fails even if I fully qualify everything with _root_, e.g. _root_.scala.AnyRef? We have already established in other tickets that _root_ is barely acknowledged internally; you can define a package named _root_, etc. But if _root_ were handled like the reserved word that it should be, then a parent _root_.scala.AnyRef should not require any enhanced interrogation.
        Hide
        Jason Zaugg added a comment -

        I tried that with the same glimmer of hope. But indeed _ root _ is just a convention right now.

        While we should tighten that up, I don't think we should bend over backwards for this cycle – it's easy enough to move the imports.

        Show
        Jason Zaugg added a comment - I tried that with the same glimmer of hope. But indeed _ root _ is just a convention right now. While we should tighten that up, I don't think we should bend over backwards for this cycle – it's easy enough to move the imports.
        Hide
        Paul Phillips added a comment -

        I don't either, I just wanted to establish it as a bug.

        Show
        Paul Phillips added a comment - I don't either, I just wanted to establish it as a bug.
        Show
        Adriaan Moors added a comment - https://github.com/scala/scala/pull/1700

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development