Skip to content

Fixes the method resolution logic for overloaded methods with array-typed arguments when basetype is primtive integral type - #33

Closed
unp1 wants to merge 1 commit into
jmltoolkit:mainfrom
unp1:main
Closed

Fixes the method resolution logic for overloaded methods with array-typed arguments when basetype is primtive integral type#33
unp1 wants to merge 1 commit into
jmltoolkit:mainfrom
unp1:main

Conversation

@unp1

@unp1 unp1 commented Jul 16, 2026

Copy link
Copy Markdown
Contributor

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

@wadoon

wadoon commented Jul 18, 2026

Copy link
Copy Markdown
Contributor

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

  1. Primitive Type Comparison in Boxing Logic (Line 664)
    Location: isBoxingCompatibleWithTypeSolver method

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.

  1. New Type Variable Substitution in MethodUsage (Lines 708-847)
    New method: substituteDeclaringTypeParameters() and substituteTypeVariables()

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
The main functional fix addresses overloaded method resolution when:

Methods have array-typed parameters
The component type is a primitive integral type (int, long, byte, etc.)
Methods are differentiated by parameter specificity
The change from isAssignableBy() to equals() for primitive comparison prevents incorrect boxing/widening conversions that were causing the wrong method to be selected in the KeY project's method resolution.

@github-code-quality

github-code-quality Bot commented Jul 18, 2026

Copy link
Copy Markdown
Contributor

Code Coverage Overview

Languages: Java

Java / code-coverage/jacoco-ubuntu-latest-21

The overall coverage in the main branch remains at 0%, unchanged from the main branch.

Show a code coverage summary of the most impacted files.
File main 3c1f9e7 main affe17e +/-
com/github/java...tsInserter.java 98% 97% -1%
com/github/java...JavaParser.java 75% 75% 0%
com/github/java...kenManager.java 29% 29% 0%
com/github/java...onStrategy.java 90% 90% 0%

Updated July 19, 2026 00:05 UTC
Code Coverage is in Public Preview. Learn more and provide us with your feedback.

…yped arguments when basetype is primtive integral type
@wadoon

wadoon commented Aug 9, 2026

Copy link
Copy Markdown
Contributor

cherry-picked

@wadoon wadoon closed this Aug 9, 2026
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.

2 participants