pysrc2cpg/io.joern/io.joern.pysrc2cpg/PythonAstVisitor

PythonAstVisitor

io.joern.pysrc2cpg.PythonAstVisitor

See thePythonAstVisitor companion object

class PythonAstVisitor(relFileName: String, val nodeToCode: NodeToCode, version: PythonVersion)(implicit withSchemaValidation: ValidationMode) extends PythonAstVisitorHelpers

Attributes

Companion: object
Graph
Supertypes: trait PythonAstVisitorHelpers

class Object

trait Matchable

class Any

Members list

Value members

Concrete methods

Lowering of {x:1, y:2, **z}: { tmp = {} tmp[x] = 1 tmp[y] = 2 tmp.update(z) tmp }

Attributes

Lowering of [x for y in l for x in y]: { tmp = [] ( for y in l: for x in y: tmp.append(x) ) tmp }

Attributes

Lowering of {x for y in l for x in y}: { tmp = {} ( for y in l: for x in y: tmp.add(x) ) tmp }

Attributes

Lowering of {k:v for y in l for k, v in y}: { tmp = {} ( for y in l: for k, v in y: tmp[k] = v ) tmp }

Attributes

Lowering of (x for y in l for x in y): { tmp = .genExp ( for y in l: for x in y: tmp.append(x) ) tmp } This lowering is not quite correct as it ignores the lazy evaluation of the generator expression. Instead it just mimics the list comprehension lowering but for now this is good enough.

Attributes

TODO For now this function compromises on the correctness of the lowering in order to get some data flow tracking going.

For constructs like x.func() we assume x to be the instance which is passed into func. This is not true since the instance method object gets the instance already bound/captured during function access. This becomes relevant for constructs like: x.func = y.func <- y.func is class method object x.func() In this case the instance passed into func is y and not x. We cannot represent this in th CPG and thus stick to the assumption that the part before the "." and the bound/captured instance will be the same. For reference see: https://docs.python.org/3/reference/datamodel.html#the-standard-type-hierarchy search for "Instance methods"