fix(#17255): cannot find Scala companion module from Java #19773
Conversation
i10416
force-pushed
the
fix/cannot-find-companion-module-in-java
branch
2 times, most recently
from
5ab2e1a to
e17c97d
Compare
i10416
changed the title
i10416
changed the title
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
i10416
force-pushed
the
fix/cannot-find-companion-module-in-java
branch
from
e17c97d to
22d98d6
Compare
Avoid skipping searchin a member by the original name even when name is likely companion module name.
Co-authored-by: Jamie Thompson <[email protected]>
|
CI is failing because of #19772 |
|
Hello, thank you for opening this! I am getting to it |
| public static p.J f() { | ||
| return p.J.j; | ||
| } | ||
| public static p.Module$ module() { |
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
There was a problem hiding this comment.
When the tree reaches TASTy, this looks like
87: DEFDEF(12) 16 [module]
90: EMPTYCLAUSE
91: SELECTtpt 17 [Module$]
93: SHAREDtype 3
95: ELIDED
96: TYPEREF 19 [Module[ModuleClass]]
98: SHAREDtype 3
100: STATIC
really, tree 91 should be SELECTtpt 19 [Module[ModuleClass]].
It would be very nice to perhaps also replace typeName("Module$") with typeName("Module").moduleClassName in typedSelect in Typer
There was a problem hiding this comment.
can leave this to follow-up, as it is still better than status quo. However this does rely on the compiler (aka all TASTy clients) intrinsically knowing how to resolve Module$ when the definition is actually Module[ModuleClass]
There was a problem hiding this comment.
Thank you for reviewing. I will investigate #19806 too.
There was a problem hiding this comment.
I'm not familiar with TASTy, so it may take a while...
There was a problem hiding this comment.
The way to solve this is in typedSelect replacing the name in the Select tree, in the same way you did in javaFindMember
There was a problem hiding this comment.
How can I test TASTy?(or make sure SELECTtpt 17 [Module$] is replaced with
SELECTtpt 19 [Module[ModuleClass]] because testp/pos does not seem to detect the difference...)
There was a problem hiding this comment.
you can do it manually with the -Yprint-tasty flag which will print to the console any generated TASTy after pickler phase, make sure you use the required -Yjava-tasty also so that you generate tasty for java sources
Test imported type as well as fully-qualified type to check `findRef` codepath. Co-authored-by: Jamie Thompson <[email protected]>
|
Thank you very much for contributing this fix! I noticed its been a long time since you opened that issue originally, its probably annoying it didn't get any attention |
To find Scala companion mudule from Java, we should strip module suffix
$.This
provides workaroundfixes #17255 as well as forward-port scala/scala#10644., 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.Related to scala/scala#10644