Better support for language(s) in components and result

[oxisto]

This PR introduces a new UnknownLanguage instead of making Node.language nullable. Furthermore, it introduces a new MultipleLanguages language that is composed of several ones. This is used for components and translation results.

Fixes #1899

[codecov]

Codecov Report

Attention: Patch coverage is 76.62338% with 18 lines in your changes missing coverage. Please review.

Project coverage is 77.11%. Comparing base (9f0e957) to head (85c2db9).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
...tlin/de/fraunhofer/aisec/cpg/frontends/Language.kt	86.95%	1 Missing and 2 partials ⚠️
...cpg/graph/statements/expressions/BinaryOperator.kt	40.00%	1 Missing and 2 partials ⚠️
...tlin/de/fraunhofer/aisec/cpg/console/Extensions.kt	0.00%	2 Missing ⚠️
...ofer/aisec/cpg/frontends/cxx/DeclarationHandler.kt	50.00%	0 Missing and 2 partials ⚠️
...ain/kotlin/de/fraunhofer/aisec/cpg/ScopeManager.kt	50.00%	0 Missing and 1 partial ⚠️
...otlin/de/fraunhofer/aisec/cpg/TranslationResult.kt	50.00%	1 Missing ⚠️
.../kotlin/de/fraunhofer/aisec/cpg/graph/Component.kt	50.00%	1 Missing ⚠️
...hofer/aisec/cpg/graph/types/FunctionPointerType.kt	0.00%	1 Missing ⚠️
...kotlin/de/fraunhofer/aisec/cpg/graph/types/Type.kt	50.00%	1 Missing ⚠️
...er/aisec/cpg/passes/ControlFlowSensitiveDFGPass.kt	0.00%	0 Missing and 1 partial ⚠️
... and 2 more

Additional details and impacted files

Files with missing lines	Coverage Δ
...main/kotlin/de/fraunhofer/aisec/cpg/TypeManager.kt	85.41% <100.00%> (+2.08%)	⬆️
...kotlin/de/fraunhofer/aisec/cpg/graph/Interfaces.kt	90.00% <ø> (ø)
.../main/kotlin/de/fraunhofer/aisec/cpg/graph/Name.kt	82.22% <100.00%> (ø)
.../main/kotlin/de/fraunhofer/aisec/cpg/graph/Node.kt	87.64% <100.00%> (+0.14%)	⬆️
...otlin/de/fraunhofer/aisec/cpg/graph/NodeBuilder.kt	71.42% <ø> (-0.90%)	⬇️
...otlin/de/fraunhofer/aisec/cpg/graph/OverlayNode.kt	100.00% <100.00%> (ø)
...otlin/de/fraunhofer/aisec/cpg/graph/TypeBuilder.kt	52.50% <100.00%> (ø)
...r/aisec/cpg/graph/declarations/ValueDeclaration.kt	92.85% <100.00%> (+3.57%)	⬆️
...g/graph/statements/expressions/AssignExpression.kt	68.18% <100.00%> (+3.03%)	⬆️
...sec/cpg/graph/statements/expressions/Expression.kt	96.29% <100.00%> (ø)
... and 29 more

... and 4 files with indirect coverage changes

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

[konradweiss]

Looks good to me, although, I have some comments that we should consider.

Also I am think we may want to have a NoLanguage language, to represent a node not having any language. This notions was previously captured by the nullness that I gladly see gone here. There is a clear difference between UnknownLanugage and NoLanguage as UnknownLanguage may be latter inferred. An example of nodes with not language are OverlayNodes, and there may be more in the future. If we decide to not introduce a a NoLanguage in this PR, which would not hinder merging IMO, we should then plan what our heuristic is to assign languages in this case: Language of an associated node that definitely has a language or a MultipleLanguages with no languages?

[oxisto]

Looks good to me, although, I have some comments that we should consider.

Also I am think we may want to have a NoLanguage language, to represent a node not having any language. This notions was previously captured by the nullness that I gladly see gone here. There is a clear difference between UnknownLanugage and NoLanguage as UnknownLanguage may be latter inferred. An example of nodes with not language are OverlayNodes, and there may be more in the future. If we decide to not introduce a a NoLanguage in this PR, which would not hinder merging IMO, we should then plan what our heuristic is to assign languages in this case: Language of an associated node that definitely has a language or a MultipleLanguages with no languages?

I like the idea about NoLanguage, I can implement this here as well. I guess this would be the default language of overlay nodes then? The rest of the (AST) nodes should have UnknownLanguage as default?

[konradweiss]

Looks good to me, although, I have some comments that we should consider.
Also I am think we may want to have a NoLanguage language, to represent a node not having any language. This notions was previously captured by the nullness that I gladly see gone here. There is a clear difference between UnknownLanugage and NoLanguage as UnknownLanguage may be latter inferred. An example of nodes with not language are OverlayNodes, and there may be more in the future. If we decide to not introduce a a NoLanguage in this PR, which would not hinder merging IMO, we should then plan what our heuristic is to assign languages in this case: Language of an associated node that definitely has a language or a MultipleLanguages with no languages?

I like the idea about NoLanguage, I can implement this here as well. I guess this would be the default language of overlay nodes then? The rest of the (AST) nodes should have UnknownLanguage as default?

Having different default Languages is a good idea, the more specific the better, so UnknownLanguage for ASTNodes and NoLanguage for OverlayNodes sounds good :)