So far so good. For comparison, we can compare list() above, that is not missing (FYI). But, in the pointer analysis, map() maps to nothing:
[Node: <Code body of function Lscript A.py/f> Context: CallStringContext: [ script A.py.do()LRoot;@113 ], v8] --> []
By contrast, list() is populated:
[Node: <Code body of function Lscript A.py/f> Context: CallStringContext: [ script A.py.do()LRoot;@113 ], v5] --> [[com.ibm.wala.cast.python.ipa.summaries.BuiltinFunctions$BuiltinFunction@9053b33]]
One consequence of this issue is that a lambda given to map() is not showing in the call graph. In other words, there is no call graph node for the lambda above, and subsequently, we have no node for fun_with_side_effects either.
Digression
The map() function returns an iterator, but there is no such type in PythonTypes. We would seemingly have to add it.
List comprehensions do work, and I would think lambdas would be similar if they are not also implemented. It's just tough to see if they are if the functions that take them as arguments aren't implemented.
The
map()
built-in function is missing, which has consequences for lambdas. Consider the following code:The IR for
f()
:So far so good. For comparison, we can compare
list()
above, that is not missing (FYI). But, in the pointer analysis,map()
maps to nothing:By contrast,
list()
is populated:One consequence of this issue is that a lambda given to
map()
is not showing in the call graph. In other words, there is no call graph node for the lambda above, and subsequently, we have no node forfun_with_side_effects
either.Digression
map()
function returns an iterator, but there is no such type inPythonTypes
. We would seemingly have to add it.