Skip to content

Conversation

@tanishiking
Copy link
Member

Previously, javaSig0 only collected type parameter names
from the immediate enclosing class when generating Java generic signatures for methods.

However, this isn't enough with nested classes where outer
class type parameters could clash with method-level type parameters.

Now we iterate all enclosing classes to collect their type
parameter names, to avoid name conflicts.

Fixes #24619


Also, in 4afe938, I refactored javaSig0 to collect class-level type parameter names in a Map[String, Name]. This allowed us to eliminate the typeParamSigWithName helper method. Does this somewhat align with your suggestion in #24567 (comment) ? @hamzaremmal

Previously, `javaSig0` only collected type parameter names
from the immediate enclosing class when generating Java generic signatures for methods.

However, this isn't enough with nested classes where outer
class type parameters could clash with method-level type parameters.

Now we iterate all enclosing classes to collect their type
parameter names, to avoid name conflicts.

Fixes scala#24619
@tanishiking tanishiking marked this pull request as ready for review December 2, 2025 09:54
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.

Nested classes' generic signatures for mixin forwarders conflicts type parameter names

2 participants