You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We now formulate local flow steps based on
`DefinitionNode`s, instead of just
`AssignmentDefinition`s.
This collects all logic around definitions into
`DefinitionNode` and avoids extra cases in the
flow relations.
It also allows a few more definitions needed for variable
capture. These are currently excluded from `AssignmentDefinition`
because they are not `TEssaNodeDefinition`s because
they are not considered live.
(`SsaComputeImpl::variableDefine` holds, but
`Liveness::liveAtExit` does not).
`DefinitionNode` includes parameter definitions
from default values, which should be jump steps.
So we split the definitions into local and jumps
by looking at the enclosing callables.
`DefinitionNode` did not include `with`-definitions,
so that has been added. Like parameter definitions,
this case of `DefinitionNode` must be excluded from
`assignment_definition`.
Finally, we incur a dataflow inconsistency for a
non-sensical assignment in test code. This we simply accept.
The code reads
```python
len(unknown()) = "foo"
```
which makes the target of the flow edge a post-update node.
// a parameter with a default value, since the parameter will be in the scope of the
509
-
// function, while the default value itself will be in the scope that _defines_ the
510
-
// function.
511
-
exists(ParameterDefinitionparam|
512
-
// note: we go to the _control-flow node_ of the parameter, and not the ESSA node of the parameter, since for type-tracking, the ESSA node is not a LocalSourceNode, so we would get in trouble.
513
-
nodeFrom.asCfgNode()=param.getDefault()and
514
-
nodeTo.asCfgNode()=param.getDefiningNode()
515
-
)
494
+
// Non-local definitions, such as assignment of a parameters default value.
0 commit comments