indiscriminate creation of package symbols (package resolution with rando dirs)

[scabug]

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.

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-6039?orig=1 Reporter: @paulp

[scabug]

@adriaanm said: Eugene, assigned to you because packages (and especially what goes into the magic scala package) are closely related to mirrors.

[scabug]

@paulp said: By the way, I just tried my reduced example and it compiled; but the whole reason I was looking at it is that it is still driving me nuts, nuts, nuts. So don't anyone close this bug because they can't reproduce it - I am reproducing it ten times a day. I don't have a foolproof reproduction system yet but with this kind of practice it will come.

[scabug]

@xeno-by said: Since it seemingly only affects code inside the scala package, this isn't user code. Demoting to major.

[scabug]

@adriaanm said (edited on Jul 19, 2012 11:47:24 AM UTC): it affects code everywhere as far as I can tell:

class Ok extends util.DynamicVariable[Int](0)
class Bippy extends tools.nsc.Settings()

causes

t6039.scala:2: error: object nsc is not a member of package tools
class Bippy extends tools.nsc.Settings()
                          ^
one error found

note that there is no error for the first line

[scabug]

@paulp said: This affects code everywhere and I stand by criticality. This is definitely a regression and has ruinously damaged my ability to perform less than full recompiles.

[scabug]

@xeno-by said: This bug is unrelated to #5943, because that one is caused by toolboxes using the empty context instead of a context that includes prelude imports.

[scabug]

@xeno-by said: Adriaan, Paul, I can't reproduce the bug on any of your snippets. Could you please elaborate?

[scabug]

@paulp said: Can't elaborate on this transcript. Something in your environment probably leads to it never happening, otherwise you'd have been driven as nuts as I have been.

% ./build/pack/bin/scala -version
Scala code runner version 2.11.0-20120730-173724-8a2df611d2 -- Copyright 2002-2011, LAMP/EPFL
% ./build/pack/bin/scalac 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

Some debugging.

[log typer] qual = tools:<root>.this.tools.type
Symbol=package tools
symbol-info = <root>.this.tools.type
scope-id = 1329670080
members = List()
name = nsc
found = <none>
owner = trait FrontEnds
warning: issue error: object nsc is not a member of package <root>.this.tools
src/compiler/scala/reflect/makro/runtime/FrontEnds.scala:44: error: object nsc is not a member of package <root>.this.tools
    case reporter: tools.nsc.reporters.AbstractReporter => reporter.displayPrompt()
                         ^
[log typer] set error: tools.nsc

The first time "tools" appears in the debug output is when the scala.tools.reflect package object is loaded.

[log typer(->parser)] [class] >> scala.tools.reflect.package
[log typer(->parser)] [class] << scala.tools.reflect.package
[log typer(->parser)] ClassfileLoader setting package.associatedFile = /scratch/trunk5/build/pack/lib/scala-compiler.jar(scala/tools/reflect/package.class)
[log typer(->parser)] [class] >> scala.tools.reflect.FrontEnds
[log typer(->parser)] [class] << scala.tools.reflect.FrontEnds
[log typer(->parser)] ClassfileLoader setting FrontEnds.associatedFile = /scratch/trunk5/build/pack/lib/scala-compiler.jar(scala/tools/reflect/FrontEnds.class)
[log typer] [class] >> scala.tools.nsc.package
[log typer] [class] << scala.tools.nsc.package
[log typer] ClassfileLoader setting package.associatedFile = /scratch/trunk5/build/pack/lib/scala-compiler.jar(scala/tools/nsc/package.class)
[log typer] [class] >> scala.tools.nsc.Global
[log typer] [class] << scala.tools.nsc.Global
[log typer] ClassfileLoader setting Global.associatedFile = /scratch/trunk5/build/pack/lib/scala-compiler.jar(scala/tools/nsc/Global.class)
[log typer] [class] >> scala.tools.nsc.symtab.package
[log typer] [class] << scala.tools.nsc.symtab.package

[scabug]

@paulp said: It compiles like this:

% ./build/pack/bin/scalac -classpath ./build/pack/lib/'*' src/compiler/scala/reflect/makro/runtime/FrontEnds.scala

Have there been advances in the field of scalac classpath isolation which I haven't yet read about in my journals?

[scabug]

@paulp said: 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.

[scabug]

@paulp said: 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.

[scabug]

@xeno-by said: At least it's a consolation that we've got to the bottom of it.

[scabug]

@paulp said: 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.

[scabug]

@paulp said: 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.

[SethTisue]

clear what the problem is, not clear what the solution might be.