Skip to content

Conversation

@WojciechMazur
Copy link
Contributor

Backports #24567 to the 3.8.0-RC3.

PR submitted by the release tooling.

…r names

Fixes #24134

f99dba2 started emitting Java generic signature for mixin forwarders.

However, when generating Java generic signatures for mixin forwarders,
method-level type parameters could shadow class-level type parameters with the same name.

For example, when `JavaPartialFunction[A, B]` implements
`PartialFunction1[A, B]`,

```scala
trait Function1[-T1, +R]:
  def compose[A](g: A => T1): A => R = ???

trait PartialFunction[-A, +B] extends Function1[A, B]:
  def compose[R](k: PartialFunction[R, A]): PartialFunction[R, B] = ???

abstract class JavaPartialFunction[A, B] extends PartialFunction[A, B]
```

the generated mixin forwarder for `compose` in Function1 was like:

```java
public abstract class JavaPartialFunction<A, B> implements scala.PartialFunction<A, B> {
  public <A> scala.Function1<A, B> compose(scala.Function1<A, A>);
```

which is obviously incorrect, the type parameter `A` of
`compose[A]` is shadowed by the `A` in `JavaPartialFunction<A, B>`.

The `compose`'s type parameter should use an unique name like:

```java
public abstract class JavaPartialFunction<A, B> implements scala.PartialFunction<A, B> {
  public <T> scala.Function1<T, B> compose(scala.Function1<T, A>);
```

This commit fix the problem by
- Tracks class-level type parameter names when generating
  method signatures
- Renames conflicting method-level type parameters (A → A1,
  A2, etc.)

[Cherry-picked 4e284c5]
@WojciechMazur WojciechMazur merged commit 917f2b0 into release-3.8.0 Dec 2, 2025
61 checks passed
@WojciechMazur WojciechMazur deleted the release-3.8.0_backport-24567 branch December 2, 2025 12:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants