Compilation of objects in Scala with special access privileges fail to compile #127
Comments
|
Thanks for the report. Does this class exist in your source code? Is |
|
Hi @javeleon, could you please confirm this issue is fixed? We'd like to close it asap. |
|
Closing, if this is still an issue, please reopen. /cc @javeleon |
|
I'm getting this with a scala |
|
If you have any kind of reproduction (minimised most appreciated) we can reopen (or open a new issue). |
class Foo {
private[Foo] object Bar
}oughta do it (I checked) |
|
Wow, that's literally enough. |
|
Working for a fix to this now. PR will probably happen today. |
|
Cool, moved to the 1.0.3 milestone then. |
jvican
changed the title
jvican
added a commit
to scalacenter/zinc
that referenced
this issue
Oct 13, 2017
It looks like scalac encodes access rights of objects in their names. To make sure that we get the right simple names, we need to use `unexpandedName` instead of `name` which will decipher these access rights and return their simple names insted (with all the previous `$$` prefixes stripped out).
jvican
added a commit
to scalacenter/zinc
that referenced
this issue
Oct 13, 2017
It looks like scalac encodes access rights of objects in their names. To make sure that we get the right simple names, we need to use `unexpandedName` instead of `name` which will decipher these access rights and return their simple names insted (with all the previous `$$` prefixes stripped out).
jvican
added a commit
to scalacenter/zinc
that referenced
this issue
Oct 13, 2017
It looks like scalac encodes access rights of objects in their names. To make sure that we get the right simple names, we need to use `unexpandedName` instead of `name` which will decipher these access rights and return their simple names insted (with all the previous `$$` prefixes stripped out).
dwijnand
added a commit
to dwijnand/zinc
that referenced
this issue
Oct 24, 2017
* 1.0.x: Fix sbt#127: Use `unexpanded` name instead of `name` Add pending test case for issue/127 source-dependencies / patMat-scope workaround Fixes undercompilation on inheritance on same source Add real reproduction case for sbt#417 Add trait-trait-212 for Scala 2.12.3 Fix source-dependencies/sealed Import statement no longer needed Move mima exclusions to its own file Move REPL related xsbti Java to correct module make LoggedReporter fields lazy sbt.version=1.0.2 use neo-sbt-scalafmt Fix ConsoleInterface binding things properly^2
|
Fixed in #431 |
|
This is the second time an issue is not closed after a PR referencing to it with "Fix #bla" is merged. |
dwijnand
added a commit
to dwijnand/zinc
that referenced
this issue
Nov 22, 2017
* 1.0.x: (25 commits) Add yourkit acknoledgement in the README Add header to cached hashing spec Add headers to missing files Fix sbt#332: Add sbt-header back to the build Update sbt-scalafmt to 1.12 Make classpath hashing more lightweight Fix sbt#442: Name hash of value class should include underlying type source-dependencies/value-class-underlying: fix test Ignore null in generic lambda tparams Improve and make scripted parallel Fix sbt#436: Remove annoying log4j scripted exception Fix sbt#127: Use `unexpanded` name instead of `name` Add pending test case for issue/127 source-dependencies / patMat-scope workaround Fixes undercompilation on inheritance on same source Add real reproduction case for sbt#417 Add trait-trait-212 for Scala 2.12.3 Fix source-dependencies/sealed Import statement no longer needed Move mima exclusions to its own file ... Conflicts: internal/zinc-apiinfo/src/main/scala/sbt/internal/inc/ClassToAPI.scala zinc/src/main/scala/sbt/internal/inc/MixedAnalyzingCompiler.scala The ClassToAPI conflict is due to: * sbt#393 (a 1.x PR), conflicting with * sbt#446 (a 1.0.x PR). The MixedAnalyzingCompiler conflict is due to: * sbt#427 (a 1.x PR), conflicting with * sbt#452 (a 1.0.x PR).
dwijnand
added a commit
to dwijnand/zinc
that referenced
this issue
Nov 23, 2017
* 1.0.x: (28 commits) Split compiler bridge tests to another subproject Implement compiler bridge for 2.13.0-M2 Add yourkit acknoledgement in the README "sbt '++ 2.13.0-M2!' compile" does not work with sbt 1.0.0 Add header to cached hashing spec Add headers to missing files Fix sbt#332: Add sbt-header back to the build Update sbt-scalafmt to 1.12 Make classpath hashing more lightweight Fix sbt#442: Name hash of value class should include underlying type source-dependencies/value-class-underlying: fix test Ignore null in generic lambda tparams Improve and make scripted parallel Fix sbt#436: Remove annoying log4j scripted exception Fix sbt#127: Use `unexpanded` name instead of `name` Add pending test case for issue/127 source-dependencies / patMat-scope workaround Fixes undercompilation on inheritance on same source Add real reproduction case for sbt#417 Add trait-trait-212 for Scala 2.12.3 ... Conflicts: internal/zinc-apiinfo/src/main/scala/sbt/internal/inc/ClassToAPI.scala project/build.properties zinc/src/main/scala/sbt/internal/inc/MixedAnalyzingCompiler.scala The ClassToAPI conflict is due to: * sbt#393 (a 1.x PR), conflicting with * sbt#446 (a 1.0.x PR). The build.properties conflict is due to different PRs bumping sbt.version from 1.0.0 to 1.0.2 to 1.0.3. (sbt#413, sbt#418, sbt#453). The MixedAnalyzingCompiler conflict is due to: * sbt#427 (a 1.x PR), conflicting with * sbt#452 (a 1.0.x PR).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Whenever I try to compile a Java project with inner classes in it using Zinc I get the following stacktrace:
The text was updated successfully, but these errors were encountered: