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
indiscriminate creation of package symbols (package resolution with rando dirs) #6039
Comments
Imported From: https://issues.scala-lang.org/browse/SI-6039?orig=1 |
@adriaanm said: |
@paulp said: |
@xeno-by said: |
@adriaanm said (edited on Jul 19, 2012 11:47:24 AM UTC): 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 |
@paulp said: |
@xeno-by said: |
@paulp said:
Some debugging.
The first time "tools" appears in the debug output is when the scala.tools.reflect package object is loaded.
|
@paulp said:
Have there been advances in the field of scalac classpath isolation which I haven't yet read about in my journals? |
@paulp said:
It will compile with any classpath, but not if given no classpath (on the command line.) Whatever that translates to. |
@paulp said: |
@xeno-by said: |
@paulp said: |
@paulp said: |
clear what the problem is, not clear what the solution might be. |
This has been driving me nuts:
Reduced example:
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.
The text was updated successfully, but these errors were encountered: