Renaming proposal for subtree searching extension functions

[konradweiss]

Renaming extension functions that search in the sub tree or ancestor chain to differentiate them from normal functions on those graph objects.

This PR renames extensions functions to more clearly differentiate them from several properties on nodes as there was a naming ambiguity. Sometimes, depending on the imports, it was unclear that all nodes of a certain type in the AST-Subtree were collected instead of simply accessing the direct ast children, e.g. statements.

This PR refactors allChildren to allDescendants and all functions using allChildren and then accessing a fraction of the nodes in the subtree by filtering for the type or some condition. The extension gets the prefix all and the previous name is capitalized. An Example: statements is now allStatements and therefore users will know that if they use statements they access the children and if they use allStatements they will access all descendant statements. While users will not know of the existence of allStatements and the prefix all it should be discoverable through any IDE and then we clearly avoid the ambiguity.

[codecov]

Codecov Report

Attention: Patch coverage is 69.49153% with 36 lines in your changes missing coverage. Please review.

Project coverage is 77.41%. Comparing base (f223faf) to head (b225dca).

✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
...kotlin/de/fraunhofer/aisec/codyze/console/Nodes.kt	20.00%	0 Missing and 4 partials ⚠️
...kotlin/de/fraunhofer/aisec/cpg/graph/Extensions.kt	90.47%	3 Missing and 1 partial ⚠️
...tlin/de/fraunhofer/aisec/cpg/frontends/Language.kt	0.00%	1 Missing and 2 partials ⚠️
...de/fraunhofer/aisec/cpg/passes/CompressLLVMPass.kt	0.00%	0 Missing and 3 partials ⚠️
...aisec/cpg/frontends/python/PythonValueEvaluator.kt	0.00%	0 Missing and 3 partials ⚠️
...fer/aisec/cpg/graph/statements/ForEachStatement.kt	0.00%	2 Missing ⚠️
...unhofer/aisec/cpg/graph/statements/ForStatement.kt	0.00%	2 Missing ⚠️
...hofer/aisec/cpg/graph/statements/WhileStatement.kt	0.00%	2 Missing ⚠️
...otlin/de/fraunhofer/aisec/cpg/query/FlowQueries.kt	66.66%	1 Missing ⚠️
...asses/concepts/memory/cxx/CXXDynamicLoadingPass.kt	0.00%	0 Missing and 1 partial ⚠️
... and 11 more

Additional details and impacted files

Files with missing lines	Coverage Δ
.../fraunhofer/aisec/codyze/console/ConsoleService.kt	55.93% <100.00%> (ø)
...rc/main/kotlin/de/fraunhofer/aisec/codyze/Sarif.kt	75.22% <100.00%> (ø)
.../kotlin/de/fraunhofer/aisec/cpg/graph/Extension.kt	40.00% <100.00%> (ø)
...raunhofer/aisec/cpg/passes/concepts/ConceptPass.kt	81.25% <100.00%> (ø)
...nhofer/aisec/cpg/passes/concepts/EOGConceptPass.kt	89.06% <100.00%> (ø)
...aisec/cpg/passes/concepts/LoadPersistedConcepts.kt	67.07% <100.00%> (ø)
...ec/cpg/passes/concepts/config/ProvideConfigPass.kt	66.07% <100.00%> (ø)
...oncepts/logging/python/PythonLoggingConceptPass.kt	88.88% <100.00%> (ø)
...in/de/fraunhofer/aisec/cpg/graph/builder/Fluent.kt	86.72% <ø> (ø)
...lin/de/fraunhofer/aisec/cpg/helpers/RegionUtils.kt	86.36% <100.00%> (ø)
... and 31 more

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

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[KuechA]

This breaks the API, so it will probably be part of CPG version 11. Also, the changes require updating the documentation.

[oxisto]

Before we do that I have another suggestion which we might do first. Currently, these extension functions work on all "nodes", which is extremely confusing since they should actually only work on AST Nodes. I would therefore suggest to add an abstract class ASTNode which lives in between Node and the basic AST nodes such as statement, etc.

Then we can make sure that things like allMethods only work on ASTNode nodes. We might need to check certain functions that they return ASTNodes instead of a regular Node when appropriate.

When we have that, we should also see if certain properties such as DFG also only make sense on AST Nodes (and possibly overlay nodes), because currently its possible to add DFG / EOG to a Type or a Scope, which is extremely confusing and error-prone.

[konradweiss]

.ast.functions.where {} could be solved with a form of graph traversal or lazy function. () with invokes would be a shorthand for evaluation. I will start with the api first and then implement the functionality. Other Ideas:

• Functions with different return types depending on the calling context.