Fixes the method resolution logic for overloaded methods with array-typed arguments when basetype is primtive integral type - #33
Conversation
|
I tried to understand this PR, but there were too many formatting changes. Github Copilot tells me this: Based on the PR details and code analysis, here are the non-cosmetic behavioral changes in this PR: Key Behavioral Changes
Before: return expectedPrimitive.isAssignableBy(actualPrimitive);After: // assumption: we only end here during recursive descend of an array type
return expectedPrimitive.equals(actualPrimitive);Impact: This is the critical fix for the issue. When comparing two primitive types (especially in array contexts), the logic now requires exact equality instead of assignability. This fixes method resolution for overloaded methods with array-typed arguments when the base type is a primitive integral type. Example scenario: For methods like format(String, int[]) vs format(String, Object[]), when resolving with primitive array arguments, the new logic ensures primitives only match exactly, preventing incorrect method selection.
Impact: These new methods properly handle type variable substitution for inherited generic methods. This ensures that when a method is inherited from a generic ancestor interface/class, the type variables are correctly substituted through the inheritance chain. Example: For List.forEach(Consumer<? super T>), this ensures T is properly substituted with String before type checking. Summary Methods have array-typed parameters |
Code Coverage OverviewLanguages: Java Java / code-coverage/jacoco-ubuntu-latest-21The overall coverage in the Show a code coverage summary of the most impacted files.
Updated |
…yped arguments when basetype is primtive integral type
|
cherry-picked |
Fixes the issue reported in KeYProject/key#3933
We could not test the fix as the compiled jars could not loaded in KeY:
cannot find symbol
import com.github.javaparser.ast.key.KeyRangeExpression;
^
symbol: class KeyRangeExpression