Closely related to libsolidity/ast/CallGraph.* (graph structure) and libsolidity/analysis/FunctionCallGraph.* (generation of graph), but with the following key differences:
The new call graph does not have to be concerned with the global entry point nor with the "internal dispatch" node.
Instead, we just need a graph that connects every function to all the internal functions that it calls or mentions (note: a mere mention without a direct call in the existing call graph on develop is connected to the internal dispatch node - in our new call graph, we want a direct connection between the calling and the called function in this case)
Uncalled free functions / disconnected sets of free functions should also be part of the graph (i.e. visit all functions, not merely start from external entry points)
Modifiers do not need to be handled (failing assertion "unsupported" for now)
Also unary and binary operators and member access can simply fail an assertion in the first version (will later need to be associated with type class information, once experimental analysis is further split).
Ignore the distinction between "creation context" and "runtime context" for now (failing assertions on constructors should do it - they won't be allowed in experimental solidity for now anyways).
So basically what we need is just a map from function definitions that maps to all functions that are called or mentioned within the respective function.
Prepare a call graph to be used in the context of Pass 4 of https://notes.ethereum.org/_OSmtx9aQAOHQXwa60IDsQ
Closely related to
libsolidity/ast/CallGraph.*
(graph structure) andlibsolidity/analysis/FunctionCallGraph.*
(generation of graph), but with the following key differences:develop
is connected to the internal dispatch node - in our new call graph, we want a direct connection between the calling and the called function in this case)So basically what we need is just a map from function definitions that maps to all functions that are called or mentioned within the respective function.