Open msridhar opened 2 weeks ago
A rough approach to an implementation might be to first iterate over all methods, find all potential lambda creation sites, and create the appropriate LambdaSummaryClass
object for each lambda and add it to the ClassHierarchy
. Then, compute the CHACallGraph
as usual. This approach could have a negative impact on running time; so probably lambda support should be optional?
Right now, even CHACallGraph
only includes methods reachable from provided entrypoints. It'd be nice if we only constructed LambdaSummaryClasses
for lambdas in those reachable methods. This might require some kind of second pass to add new edges to previously encountered call sites though. Maybe we could just do two passes and be done with it? EDIT: nope, in the presence of nested lambdas we'd have to go to a fixed point.
This is a notable gap in WALA's call graph construction algorithms for Java bytecode. I haven't worked out the full algorithm but I don't think this should be too hard to support. Need to somehow pattern match on the IR or bytecodes and model the class that gets generated for the lambda. Not sure if we want to also update the
ClassHierarchy
in the process.