DFG Hotfix

[vfsrfs]

Fixes multiple issues with incorrect DFG edges.

• VariableDeclaration should not contain any outgoing DFG edges.
• The replacement of DFG edges in an assignment must be delayed until the assignment has been completely processed, in order to avoid the issue that a rhs DeclaredReferenceExpression has a dfg edge from the las. E.g.: a = a + b.

Graph Changes

None

Interface Changes

None

[oxisto]

Ah, codyze will fail for now because it is not yet on the 3.0.0. branch

[vfsrfs]

Ah, codyze will fail for now because it is not yet on the 3.0.0. branch

Why is this an issue? As far as I know the Master branch is 3.0.0 or am I wrong?

[oxisto]

Ah, codyze will fail for now because it is not yet on the 3.0.0. branch

Why is this an issue? As far as I know the Master branch is 3.0.0 or am I wrong?

I was referring to the fact that Codyze still uses pre-3.0.0 before the node structuring, that is why the external codyze check fails.

[konradweiss]

Ah, codyze will fail for now because it is not yet on the 3.0.0. branch

Why is this an issue? As far as I know the Master branch is 3.0.0 or am I wrong?

I was referring to the fact that Codyze still uses pre-3.0.0 before the node structuring, that is why the external codyze check fails.

Why do we have a check codyze test in our CI? The codyze is supposed to fail when we make bigger changes, such a test should not be done in CPG, adaptations to the CPG in Codyze should happen on releases and not before merging a PR in the CPG.

[konradweiss]

@vfsrfs Looks like most is fixed. We still have cyles when we use these self referencing RW references as a--. Currently the the Graph there looks like this:
we have to remove these cycles, so either we directly draw the edge from such operators like '--' '/=' '+=' etc. to the Declaration instead of going over the referenz. These changes would have to be done in the AST construction and not the DFG-refinement. Lastly there is the Task to create a new Uninitialized node for the case where we have 'int a;' with the purpose to newer have to draw DFGs from the declaration itself, as the declaration also has incoming edges from every write and this would create cylces.

[vfsrfs]

@vfsrfs Looks like most is fixed. We still have cyles when we use these self referencing RW references as a--. Currently the the Graph there looks like this: we have to remove these cycles, so either we directly draw the edge from such operators like '--' '/=' '+=' etc. to the Declaration instead of going over the referenz. These changes would have to be done in the AST construction and not the DFG-refinement. Lastly there is the Task to create a new Uninitialized node for the case where we have 'int a;' with the purpose to newer have to draw DFGs from the declaration itself, as the declaration also has incoming edges from every write and this would create cylces.

Thanks for the review 👍. I will fix the cycles caused by the unary and compound operator and add the uninitialized node.

[vfsrfs]

Ah, codyze will fail for now because it is not yet on the 3.0.0. branch

Why is this an issue? As far as I know the Master branch is 3.0.0 or am I wrong?

I was referring to the fact that Codyze still uses pre-3.0.0 before the node structuring, that is why the external codyze check fails.

Why do we have a check codyze test in our CI? The codyze is supposed to fail when we make bigger changes, such a test should not be done in CPG, adaptations to the CPG in Codyze should happen on releases and not before merging a PR in the CPG.

I agree with @konradweiss, every CPG PR will fail until codyze is updated, which means that we will have a delay for adding new features to the CPG.

[oxisto]

Ah, codyze will fail for now because it is not yet on the 3.0.0. branch

Why is this an issue? As far as I know the Master branch is 3.0.0 or am I wrong?

I was referring to the fact that Codyze still uses pre-3.0.0 before the node structuring, that is why the external codyze check fails.

Why do we have a check codyze test in our CI? The codyze is supposed to fail when we make bigger changes, such a test should not be done in CPG, adaptations to the CPG in Codyze should happen on releases and not before merging a PR in the CPG.

I agree with @konradweiss, every CPG PR will fail until codyze is updated, which means that we will have a delay for adding new features to the CPG.

It is not mandatory, you can include the check with a label. It is more a sanity check, if this changes anything on Codze. Maybe there is a way to not have it as an "error", rather a warning

It was introduced here: https://github.com/Fraunhofer-AISEC/cpg/pull/221

[sonarcloud[bot]]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities (and 0 Security Hotspots to review)
0 Code Smells

96.5% Coverage
0.0% Duplication

[vfsrfs]

Adds an UninitialezedValue initializer to VariableDeclarations without initialised to allow for propagation in the dfg pass. Fixes multiple issues with incorrect DFG edges.

• VariableDeclaration should not contain any outgoing DFG edges.

• The replacement of DFG edges in an assignment must be delayed until the assignment has been completely processed, in order to avoid the issue that a rhs DeclaredReferenceExpression has a dfg edge from the las. E.g.: a = a + b.

Graph Changes

Adds an UninitializedValue node to the graph with ingoing and outgoing EOG edges, an ingoing initializer edge and an outgoing dfg edge from/to the corresponding VariableDeclaration.

Interface Changes

None