Fix varargs overload resolution with wildcard types #24669
Merged
+77
−2
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
tanishiking
commented
Dec 4, 2025
Fixes scala#24072 When comparing overloaded methods where one is non-varargs with wildcard types (e.g., `Class[? <: T]`) and another is varargs, the non-varargs method should be preferred. Previously, the compiler failed to distinguish these methods , and results in an ambiguity error. ```scala def blub[T](a: Class[? <: T]): Unit // m1 def blub[T](a: Class[T], ints: Int*): Unit // m2 blub(classOf[Object]) // m1 should be picked, but fails to resolve ```` The problem is `compare(m1, m2)` returned 0 because: - (1). `m2` (varargs) is correctly considered "not as good" as `m1`. - (2). `m1` (non-varargs) was also considered "not as good" as `m2`. (but `m1` should be as good as `m2`! because `Class[Concrete]` can be applied to both m1 and m2). The (2) occurred because `Class[? <: T]` is not a subtype of `Class[T]` (due to invariance). Consequently, `isApplicableMethodRef(m2, Class[? <: T])` returned `false` because `isCompatible(Class[? <: T], Class[T])` returned `false` during the applicability check against the method. This commit adds special handling in `TestApplication.argOK` to check if wildcard upper bounds are compatible with their formal types during overload resolution, in addition to `isCompatible`.
tanishiking
force-pushed
the
i24072
branch
2 times, most recently
from
801fc51 to
b8e3f98
Compare
tanishiking
changed the title
odersky
requested changes
Dec 12, 2025
| // subtype of Class[T] (Class is invariant), for overload resolution we consider | ||
| // Class[? <: T] "applicable" where Class[T] is expected by checking if the | ||
| // wildcard's upper bound is a subtype of the formal type parameter. | ||
| def wildcardArgOK = |
Contributor
There was a problem hiding this comment.
The logic looks fine. My only concern here is compilation time. We should try to optimize this and only call wildcardArgOK in the (relatively rare) case where argtpe has wildcard arguments. Something like
hasWilcardArgs(argtpe) && (argtpe, formal).match ...
Use `hasWildcardArg` to quickly check if the argument type contains wildcard type arguments before performing expensive pattern matching and type comparisons.
Member
Author
|
Thank you for reviewing @odersky ! merging |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #24072
When comparing overloaded methods where one is non-varargs with wildcard types (e.g.,
Class[? <: T]) and another is varargs, the non-varargs method should be preferred.Previously, the compiler failed to distinguish these methods , and results in an ambiguity error.
The problem is
compare(m1, m2)returned 0 because:m2(varargs) is correctly considered "not as good" asm1.m1(non-varargs) was also considered "not as good" asm2. (butm1should be as good asm2! becauseClass[Concrete]can be applied to both m1 and m2).The (2) occurred because
Class[? <: T]is not a subtype ofClass[T](due to invariance). Consequently,isApplicableMethodRef(m2, Class[? <: T])returnedfalsebecauseisCompatible(Class[? <: T], Class[T])returnedfalseduring the applicability check against the method.This commit adds special handling in
TestApplication.argOKto check if wildcard upper bounds are compatible with their formal types during overload resolution, in addition toisCompatible.