Handle HKT bounds in Java generic signatures by SolalPirelli · Pull Request #25744 · scala/scala3

SolalPirelli · 2026-04-09T10:27:54Z

How much have you relied on LLM-based tools in this contribution?

zero much

How was the solution tested?

issue tests (+ 1 case inverting the arg order)

tanishiking

Overall approach looks good, but hasNested doesn't seem capture the case where expanded type's type arguments has different shape.

tanishiking · 2026-04-17T07:25:42Z

+        case TypeParamRef(binder, paramNum) =>
+          binder.paramInfos(paramNum).hi match
+            case hkt @ HKTypeLambda(_, _) =>
+              val instantiated = hkt.instantiate(a.args).dealias


[note]
.dealias is required, otherwise type M[X,Y] appears in generic signature in the test below. 👍

tanishiking · 2026-04-17T07:30:33Z

+              // However, since Java doesn't have a way to refer to HKTs in generic signatures,
+              // we must trade precision for termination by only resolving one level,
+              // otherwise we end up in infinite loops, e.g., in `X[A] <: Thing[X[A]]` we keep resolving `X -> Thing[X[A]]`.
+              val hasNested = instantiated.existsPart:


[note]

def f[A, X[T] <: Iterable[X[T]]]: X[A] = ???

this resolves to
X[A] -> Iterable[X[A]] -> Iterable[Iterable[X[A]]] -> ...

We detect X[A] in the next level (Iterable[X[A]]) and if we found a same structure in 1-level resolved signature, stop resolving.

[important]
Oh wait, but what if we have slightly different resolved type signature like:

trait RecursiveSig: def example[A, X[t] <: Iterable[X[List[t]]]](s: String): X[A] = ???

X[A] -> Iterable[X[List[A]] which doesn't captured by hasNested. It ends up infinite loop.

We should stop if we found X[...] with what ever type arguments.

thanks, that's indeed more correct and also simpler

tanishiking · 2026-04-17T07:43:59Z

@@ -0,0 +1 @@
+scala.collection.Iterable<scala.Tuple2<K, A>>


maybe we wanna move these tests into tests/generic-java-signatures instead of tests/run.

what's the purpose of this generic-java-signatures folder exactly? we could move a lot of tests in there indeed

files under tests/generic-java-signatures runs in separate JUnit suite

scala3/compiler/test/dotty/tools/dotc/CompilationTests.scala

Lines 181 to 184 in d23d5ef

@Test def genericJavaSignatures: Unit = {

implicit val testGroup: TestGroup = TestGroup("genericJavaSignatures")

val compilationTest = withCoverage(compileFilesInDir("tests/generic-java-signatures", defaultOptions))

runWithCoverageOrFallback[RunTestWithCoverage](compilationTest, "Run")

On the other hand, files under tests/run could be belong to multiple JUnit suite, like run (with 2 different options), pickle, and recheck. That means we could run test multiple times.

So, if the test is specific for checking java generic signatures, they would be nice to go to tests/generic-java-signatures. (While I also somtimes forget about that...). And yeah, maybe we wanna move bunch of tests in there in another PR.

Not testing multiple times is nice... also I just realized it means we don't need to explicitly add scalajs: --skip and that's already a good enough reason for me :D

I'll grep scalajs: --skip and move the ones that belong to genericJavaSignatures in another PR 👍

lrytz · 2026-04-20T12:01:45Z

@@ -0,0 +1 @@
+scala.collection.Iterable<A>


Is this right? If I expand X[A] once to its bound I get Iterable[X[List[A]], which doesn't look like Iterable[A]. It's not something changed / introduced by this PR, but worth a ticket?

No, indeed, that's not right... what should we have instead? Iterable as a raw type?

part of the problem is I don't know what the spec of these things is

is still true 16 years later, I guess (scala/bug#3249)...

A raw type is probably sound? Or a wildcard argument scala.collection.Iterable<*>?

I tried understanding what these things are supposed to be, but in another recent PR I ran into a javac assert on what I believed to be a valid signature, so I stopped trying. Let's go with a raw type here as long as tests pass.

I agree with @lrytz, from X[A] <: Iterable[X[List[A]]], the best approximation seems Iterable<?>. A raw Iterable is ok, but it loses more generic information. If javac / signature accepts it (I'm wondering when javac assert for wildcard 🤔) ideally we should have Iterable<?> here.

but I think it's good to go with raw type, and open another issue to track this?

opened #25887

tanishiking

LGTM, thanks!
I think we wanna move tests to tests/generic-java-signatures, but that can be done in another PR with other test files all together.

tanishiking · 2026-04-20T15:04:20Z

@@ -0,0 +1 @@
+scala.collection.Iterable<scala.Tuple2<K, A>>


files under tests/generic-java-signatures runs in separate JUnit suite

scala3/compiler/test/dotty/tools/dotc/CompilationTests.scala

Lines 181 to 184 in d23d5ef

@Test def genericJavaSignatures: Unit = {

implicit val testGroup: TestGroup = TestGroup("genericJavaSignatures")

val compilationTest = withCoverage(compileFilesInDir("tests/generic-java-signatures", defaultOptions))

runWithCoverageOrFallback[RunTestWithCoverage](compilationTest, "Run")

On the other hand, files under tests/run could be belong to multiple JUnit suite, like run (with 2 different options), pickle, and recheck. That means we could run test multiple times.

So, if the test is specific for checking java generic signatures, they would be nice to go to tests/generic-java-signatures. (While I also somtimes forget about that...). And yeah, maybe we wanna move bunch of tests in there in another PR.

tanishiking · 2026-04-20T15:06:10Z

@@ -0,0 +1 @@
+scala.collection.Iterable<A>


I agree with @lrytz, from X[A] <: Iterable[X[List[A]]], the best approximation seems Iterable<?>. A raw Iterable is ok, but it loses more generic information. If javac / signature accepts it (I'm wondering when javac assert for wildcard 🤔) ideally we should have Iterable<?> here.

but I think it's good to go with raw type, and open another issue to track this?

Fixes scala#15903 ## How much have you relied on LLM-based tools in this contribution? zero much ## How was the solution tested? issue tests (+ 1 case inverting the arg order)

SolalPirelli requested a review from tanishiking April 9, 2026 13:01

SolalPirelli added the needs-squashing PR whose commits should be squashed by the author or via the "Squash and Merge" button label Apr 10, 2026

tanishiking requested changes Apr 17, 2026

View reviewed changes

SolalPirelli added 2 commits April 20, 2026 13:16

Handle HKT bounds in Java generic signatures

3d0b5d8

PR feedback

206a364

SolalPirelli force-pushed the solal/15903 branch from eb44b2d to 206a364 Compare April 20, 2026 11:27

SolalPirelli requested a review from tanishiking April 20, 2026 11:28

lrytz reviewed Apr 20, 2026

View reviewed changes

PR feedback

eb5bf68

tanishiking approved these changes Apr 20, 2026

View reviewed changes

SolalPirelli mentioned this pull request Apr 21, 2026

Decide on when to use raw vs wildcard types in Java generic signatures #25887

Open

SolalPirelli merged commit 3e2bc79 into scala:main Apr 21, 2026
45 checks passed

SolalPirelli deleted the solal/15903 branch April 21, 2026 07:09

	@Test def genericJavaSignatures: Unit = {
	implicit val testGroup: TestGroup = TestGroup("genericJavaSignatures")
	val compilationTest = withCoverage(compileFilesInDir("tests/generic-java-signatures", defaultOptions))
	runWithCoverageOrFallback[RunTestWithCoverage](compilationTest, "Run")

		@@ -0,0 +1 @@
		scala.collection.Iterable<A>

		@@ -0,0 +1 @@
		scala.collection.Iterable<A>

Conversation

SolalPirelli commented Apr 9, 2026

How much have you relied on LLM-based tools in this contribution?

How was the solution tested?

Uh oh!

tanishiking left a comment

Choose a reason for hiding this comment

Uh oh!

tanishiking Apr 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lrytz Apr 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tanishiking left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

tanishiking Apr 17, 2026 •

edited

Loading

lrytz Apr 20, 2026 •

edited

Loading