Closed jacosro closed 4 years ago
The alternative would be to add extra parameter input and output to method calls. This would be done in the PDG:
GraphNode<MethodDeclaration>
should be split into n
nodes: a GraphNode<MethodDeclaration>
and as many GraphNode<VariableDeclarator>
as needed (each parameter and global variable used, and each parameter and variable modified in such a way that the change can be seen when querying from the original position).GraphNode<? extends Statement>
needs to be traversed to find all MethodCallExpr
objects, so that input and output nodes can be generated and then connected to the corresponding method call.The "creation" of the SDG is as simple as connecting each method call and its in/out nodes to all the matching method declarations (and their in/out nodes), plus adding summary arcs between in/out nodes.
Useful material (papers):
Locating which method call has been executed with JavaParser + JavaSymbolSolver: https://tomassetti.me/resolve-method-calls-using-java-symbol-solver/
Closing this issue since it is completed for now. Opening new issues to refine it
Currently, method call nodes (i.e. nodes which contain an expression corresponding to a method call) are not represented as different nodes (they are
GraphNode
s). Maybe, it would be a good idea to represent them separately in SDG, in order to build in/out variable nodes and work with them easily. This way, a new classMethodCallNode
extending theGraphNode
class would be created, containing references to in/out variable nodes.This would only exist in the SDG, so this also implies, as the SDG is built by a composition of PDGs, that there should exist a visitor which converts
GraphNode
s from the PDG intoMethodCallNode
s@cargaji What do you think? Any alternatives?
To do:
In
andout
nodesNameExpr
) as argumentsreturn
node?