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

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

Open
scabug opened this issue Jul 7, 2012 · 16 comments
Labels
Milestone

Comments

@scabug
Copy link

scabug commented Jul 7, 2012

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
Copy link
Author

scabug commented Jul 7, 2012

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

@scabug
Copy link
Author

scabug commented Jul 11, 2012

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

@scabug
Copy link
Author

scabug commented Jul 14, 2012

@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
Copy link
Author

scabug commented Jul 19, 2012

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

@scabug
Copy link
Author

scabug commented Jul 19, 2012

@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
Copy link
Author

scabug commented Jul 19, 2012

@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
Copy link
Author

scabug commented Aug 1, 2012

@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
Copy link
Author

scabug commented Aug 1, 2012

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

@scabug
Copy link
Author

scabug commented Aug 2, 2012

@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
Copy link
Author

scabug commented Aug 2, 2012

@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
Copy link
Author

scabug commented Aug 2, 2012

@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
Copy link
Author

scabug commented Aug 2, 2012

@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
Copy link
Author

scabug commented Aug 2, 2012

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

@scabug
Copy link
Author

scabug commented Aug 2, 2012

@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
Copy link
Author

scabug commented Nov 17, 2012

@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
Copy link
Member

SethTisue commented Mar 3, 2018

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

@som-snytt som-snytt changed the title scala can no longer reliably resolve relative packages indiscriminate creation of package symbols (package resolution with rando dirs) Sep 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants