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

scala can no longer reliably resolve relative packages

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Type Checker
    • Labels:
      None

      Description

      This has been driving me nuts:

      % scalac3 -versionScala compiler version 2.10.0-20120706-081450-c632aaca8b -- Copyright 2002-2011, LAMP/EPFL
      % scalac3 -d /tmp src/compiler/scala/reflect/makro/runtime/FrontEnds.scala
      src/compiler/scala/reflect/makro/runtime/FrontEnds.scala:44: error: object nsc is not a member of package tools
          case reporter: tools.nsc.reporters.AbstractReporter => reporter.displayPrompt()
                               ^
      src/compiler/scala/reflect/makro/runtime/FrontEnds.scala:44: error: value displayPrompt is not a member of scala.tools.nsc.reporters.Reporter
          case reporter: tools.nsc.reporters.AbstractReporter => reporter.displayPrompt()
                                                                          ^
      two errors found
      

      Reduced example:

      package scala.reflect.makro
      
      class Bippy extends tools.nsc.Settings() { }
      

      It appears that scala classes are able to "opt out" of being in the scala package, which seems reasonable enough, except it is inconsistently applied. Clearly FrontEnds (among numerous other examples) is usually compiling fine. I don't yet know what the trigger is.

        Issue Links

          Activity

          Hide
          Paul Phillips added a comment -

          Actually it gets better. It also compiles like this:

          ./build/pack/bin/scalac -classpath /asdlfkjalsdfj src/compiler/scala/reflect/makro/runtime/FrontEnds.scala
          

          It will compile with any classpath, but not if given no classpath (on the command line.) Whatever that translates to.

          Show
          Paul Phillips added a comment - Actually it gets better. It also compiles like this: ./build/pack/bin/scalac -classpath /asdlfkjalsdfj src/compiler/scala/reflect/makro/runtime/FrontEnds.scala It will compile with any classpath, but not if given no classpath (on the command line.) Whatever that translates to.
          Hide
          Paul Phillips added a comment -

          Mother mother mother... it is the "tools" directory under the repository root. scalac believes it is a package "root.tools" and that "tools.nsc.foo" is nonsense. I have long been terrified of what not-yet-understood consequences were arising from the indiscriminate creation of package symbols based on whatever happens to be in one's current working directories. Now I know why.

          Show
          Paul Phillips added a comment - Mother mother mother... it is the "tools" directory under the repository root. scalac believes it is a package " root .tools" and that "tools.nsc.foo" is nonsense. I have long been terrified of what not-yet-understood consequences were arising from the indiscriminate creation of package symbols based on whatever happens to be in one's current working directories. Now I know why.
          Hide
          Eugene Burmako added a comment -

          At least it's a consolation that we've got to the bottom of it.

          Show
          Eugene Burmako added a comment - At least it's a consolation that we've got to the bottom of it.
          Hide
          Paul Phillips added a comment -

          I still consider this critical. Just because the behavior existed in the past doesn't mean it was always this common. I'm not completely oblivious, I can tell the difference between something happening all the time and something happening very rarely. It's possible the reason it happens all the time now is that someone (you?) has habitually been using relative paths like "tools.foo" when that was not the case before. In any case I'll either fix this or I will make all those paths absolute.

          Show
          Paul Phillips added a comment - I still consider this critical. Just because the behavior existed in the past doesn't mean it was always this common. I'm not completely oblivious, I can tell the difference between something happening all the time and something happening very rarely. It's possible the reason it happens all the time now is that someone (you?) has habitually been using relative paths like "tools.foo" when that was not the case before. In any case I'll either fix this or I will make all those paths absolute.
          Hide
          Paul Phillips added a comment -

          In 55b609458fd and ea0d891f238 I made all the paths absolute, as far as src/library. This is insufficient, offers no insulation against recurrence, and does not address the underlying issue at all, but it still helps a lot.

          Show
          Paul Phillips added a comment - In 55b609458fd and ea0d891f238 I made all the paths absolute, as far as src/library. This is insufficient, offers no insulation against recurrence, and does not address the underlying issue at all, but it still helps a lot.

            People

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

              Dates

              • Created:
                Updated:

                Development