Fix Aggregator, TypeAssigner, LocalNameStandardizer#741
Conversation
TypeAssigner: change augmentation in cases of BottomType to unknownType
…method finding ;)
|
@JonasKlauke SourcteType already works in finding the entryMethod ;-) |
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## develop #741 +/- ##
=============================================
- Coverage 63.74% 63.64% -0.11%
+ Complexity 3367 3360 -7
=============================================
Files 317 317
Lines 15145 15124 -21
Branches 2555 2551 -4
=============================================
- Hits 9654 9625 -29
- Misses 4601 4608 +7
- Partials 890 891 +1
☔ View full report in Codecov by Sentry. |
|
Run my code with this branch ( and with While I indeed didn't add the corresponding jar of this class to the classpath, isn't it sufficient to construct the type information in Jimple only relying on the information in the class file? |
…ierarchy.contains() <!=> view.getClass().isPresent() as signatures could be referenced from other classes which then end up in the underlying graph of the typehierarchy
|
@virusdefender thx, this should be fixed in #b270b08 |
|
thanks, it's much better now than before, but there are still a few small issues method return value is not assigned to variablethe return value of the same case,
|
…g. an Expr is a use as well
…is used in *another* essential stmt
…eed to filter for essential stmts again in the second step

from (
AggregatorTest.testIssue739()):to (which is wrong; missing staticinvoke, wrong cast to Integer insetad of String)
AggregatorTest.testIssue739():closes #739