-
Notifications
You must be signed in to change notification settings - Fork 3.1k
Use Java rules for member lookup in .java sources #7671
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
Use Java rules for member lookup in .java sources #7671
Conversation
47745f0 to
7b3790e
Compare
|
Targetting at 2.13.x, but this would be a backport candidate for 2.12.9 |
For static innner classes, we need to check in the companion module of each base classes.
…mpanion class prefix
to avoid cluttering logic that 99% of time deals with Scala
7b3790e to
29fe15b
Compare
adriaanm
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I push -f'ed my review (just a small tweak). Let me know if this looks good to you. Let's squash the commits before merging.
- Inherited type declarations are in scope in Java code - For static innner classes, we need to check in the companion module of each base classes. - Incorporate and accomodate test case from scala#6053 - Tests to java code referring to module-class owned classes via companion class prefix Backport of scala#7671
|
Backport submitted in #7738 |
- Inherited type declarations are in scope in Java code - For static innner classes, we need to check in the companion module of each base classes. - Incorporate and accomodate test case from scala#6053 - Tests to java code referring to module-class owned classes via companion class prefix Backport of scala#7671
|
"Java rules!" |
|
Awesome -- this also obviates the need for a leaky encoding in JavaParsers: scala/src/compiler/scala/tools/nsc/javac/JavaParsers.scala Lines 760 to 770 in 7c9e372
Those forwarders attempt to encode the rules that this PR implements directly. They cause issues when refchecks becomes more accurate because they are inherited. |
It's subsumed by Jason's improvements to name resolution in scala#7671. The leak yielded spurious errors in mixed Scala/Java compilation (akka-http). Also, pull up exemption for synthetic members from refchecks; it makes no sense to bother the user about members synthesized by the compiler. We could get early warnings this way, but eventually they'll pop up as VerifyErrors...
It's subsumed by Jason's improvements to name resolution in scala#7671. The leak yielded spurious errors in mixed Scala/Java compilation (akka-http).
It's subsumed by Jason's improvements to name resolution in scala#7671. The leak yielded spurious errors in mixed Scala/Java compilation (akka-http). (cherry picked from commit 8529be7)
Fixed in scala#7671, which was backported to 2.12.x in scala#7738
To find Scala companion mudule from Java in mixed sources, we should strip module suffix `$`. This provides workaround for scala#17255, but it requires some refinment to fix it because not-fully-qualified type like the following example still fails to compile due to missing symbol. ```java package example; public class Bar { private static final Foo$ MOD = Foo$.MODULE; } ``` This is because `pre` in `javaFindMember` for `Foo` in the case above is `<root>`, not `example` and therefore `pre.findMember` looks for `<root>.Foo` instead of `example.Foo`. I'm not sure whether the qualifier is intentionally dropped. References - scala#12884 - scala/scala#7671
To find Scala companion mudule from Java in mixed sources, we should strip module suffix `$`. This provides workaround for #17255, but it requires some refinment to fix it because not-fully-qualified type like the following example still fails to compile due to missing symbol. ```java package example; public class Bar { private static final Foo$ MOD = Foo$.MODULE; } ``` This is because `pre` in `javaFindMember` for `Foo` in the case above is `<root>`, not `example` and therefore `pre.findMember` looks for `<root>.Foo` instead of `example.Foo`. I'm not sure whether the qualifier is intentionally dropped. References - #12884 - scala/scala#7671 [Cherry-picked 22d98d6][modified]
No description provided.