Skip to content

Conversation

@moebarni
Copy link
Collaborator

issue: #1266

@codecov
Copy link

codecov bot commented Jul 1, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 71.56%. Comparing base (18baba8) to head (5a00c10).

Additional details and impacted files
@@              Coverage Diff              @@
##             develop    #1333      +/-   ##
=============================================
+ Coverage      71.47%   71.56%   +0.08%     
  Complexity        19       19              
=============================================
  Files            443      443              
  Lines          18468    18514      +46     
  Branches        2954     2960       +6     
=============================================
+ Hits           13200    13249      +49     
+ Misses          4156     4154       -2     
+ Partials        1112     1111       -1     
Components Coverage Δ
core 64.87% <ø> (+0.02%) ⬆️
java.core 72.56% <ø> (-0.02%) ⬇️
java.bytecode.frontend 79.68% <ø> (ø)
jimple.frontend 74.25% <ø> (ø)
apk.frontend 73.48% <ø> (ø)
interceptors 77.08% <ø> (ø)
callgraph 84.84% <100.00%> (+1.32%) ⬆️
codepropertygraph 75.12% <ø> (ø)
analysis.intraprocedural 66.24% <ø> (ø)
analysis.interprocedural 67.66% <ø> (ø)
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@moebarni moebarni requested a review from JonasKlauke July 1, 2025 08:54
@moebarni moebarni self-assigned this Jul 1, 2025
Comment on lines 104 to 114
.flatMap(
value -> {
// ClassType as returnType
if (value instanceof AbstractInvokeExpr && value.getType() instanceof ClassType) {
return Stream.of((ClassType) value.getType());
// new-expression
} else if (value instanceof JNewExpr) {
return Stream.of(((JNewExpr) value).getType());
}
return Stream.empty();
})
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we are only checking for new expressions. Method calls are not considered because first you do not check if they are constructor and second because if you would check for constructors you would consider supertypes as instaniated if the constructor contains a super() call.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rollback applied. New approach required to treat java.lang.invoke.MethodHandle (with its package-private constructor) as instantiated during RTA analysis.

Comment on lines 705 to 706
if (targetMethodSignature.getDeclClassType().equals(polymorphicMethodSigs.getDeclClassType())
&& targetMethodSignature.getName().equals(polymorphicMethodSigs.getName())) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

two cases are not covered which me might have to investigate.

  1. different parameters,
  2. subclasses of classes that contain these methods

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Created tests.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No subclasses of java.lang.invoke.MethodHandle/VarHandle possible, both classes have package-private constructors and all their implementations are package-private.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you access the annotation outside of the package?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No: 'java.lang.invoke.MethodHandle.PolymorphicSignature' is not public in 'java.lang.invoke.MethodHandle'. Cannot be accessed from outside package

@soot-oss soot-oss deleted a comment from JonasKlauke Jul 29, 2025
@JonasKlauke JonasKlauke changed the title investigate varargs param in cg Add support for var-args method calls with @PolymorphicSignature causing unmatched method signatures Jul 31, 2025
@JonasKlauke
Copy link
Collaborator

fixes also #78

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.

[Feature]: Investigate varargs parameter in the call graph algorithm Create Backport for MethodHandle/VarHandle

3 participants