Handle InitializerListExpressions as variables of ComprehensionExpressions in the DFG

[KuechA]

Adapts the ControlFlowSensitiveDFGPass to handle multiple declarations and references in the variable of ComprehensionExpressions. To enhance the readability, the logic is moved to an own function.

Fixes #1957, #2017

It further introduces a new interface HasAccess for Nodes which can be read from or written to. This allows to set the attribute access: AccessValues for more nodes than Reference and it also allows to implement a propagation logic per node class. Currently, the classes Reference, InitializerListExpression and SubscriptExpression implement this interface. It is mainly used to determine the direction of DFG edges.

[codecov]

Codecov Report

Attention: Patch coverage is 77.94118% with 15 lines in your changes missing coverage. Please review.

Project coverage is 78.24%. Comparing base (6140a2f) to head (3da26d9).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
...er/aisec/cpg/passes/ControlFlowSensitiveDFGPass.kt	82.60%	3 Missing and 1 partial ⚠️
...tatements/expressions/InitializerListExpression.kt	77.77%	1 Missing and 1 partial ⚠️
.../cpg/graph/statements/expressions/UnaryOperator.kt	83.33%	0 Missing and 2 partials ⚠️
...fer/aisec/cpg/graph/statements/ForEachStatement.kt	0.00%	0 Missing and 1 partial ⚠️
...g/graph/statements/expressions/AssignExpression.kt	75.00%	0 Missing and 1 partial ⚠️
...cpg/graph/statements/expressions/CastExpression.kt	83.33%	0 Missing and 1 partial ⚠️
.../statements/expressions/ComprehensionExpression.kt	0.00%	0 Missing and 1 partial ⚠️
...raph/statements/expressions/SubscriptExpression.kt	75.00%	0 Missing and 1 partial ⚠️
...lin/de/fraunhofer/aisec/cpg/graph/types/HasType.kt	50.00%	0 Missing and 1 partial ⚠️
...n/kotlin/de/fraunhofer/aisec/cpg/passes/DFGPass.kt	75.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

Files with missing lines	Coverage Δ
...kotlin/de/fraunhofer/aisec/cpg/graph/Interfaces.kt	90.00% <ø> (ø)
...isec/cpg/graph/statements/expressions/Reference.kt	94.28% <100.00%> (ø)
...fer/aisec/cpg/graph/statements/ForEachStatement.kt	91.66% <0.00%> (-0.65%)	⬇️
...g/graph/statements/expressions/AssignExpression.kt	71.64% <75.00%> (+0.42%)	⬆️
...cpg/graph/statements/expressions/CastExpression.kt	75.00% <83.33%> (+0.71%)	⬆️
.../statements/expressions/ComprehensionExpression.kt	57.14% <0.00%> (-1.95%)	⬇️
...raph/statements/expressions/SubscriptExpression.kt	56.41% <75.00%> (+0.85%)	⬆️
...lin/de/fraunhofer/aisec/cpg/graph/types/HasType.kt	77.77% <50.00%> (-1.64%)	⬇️
...n/kotlin/de/fraunhofer/aisec/cpg/passes/DFGPass.kt	83.24% <75.00%> (-0.46%)	⬇️
...tatements/expressions/InitializerListExpression.kt	48.64% <77.77%> (+5.31%)	⬆️
... and 2 more

... and 3 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[oxisto]

Some smaller remarks. In general this looks good, but I wonder whether we should move access to Expression.

[oxisto]

On second thought. Wouldn't it make sense to just implements this on all Expression nodes? The memory overhead is probably negligible and we would remove a lot of ugly as? HasAccess casts. Basically this should apply to all expressions.

[KuechA]

I decided against this because many Expressions cannot receive any data (i.e., AccessValues.WRITE never makes sense for them and for some, also READ might be confusing), so the access value is not useful there. Are the casts are a major concern? Any opinions on this @konradweiss ?