Package-level declarations
Types
CastResult is the result of the function Language.tryCast and describes whether a cast of one type into another is successful according to the logic of the Language.
A compilation database contains necessary information about the include paths and possible compiler flags that should be used for an individual source file. It follows the JSON Compilation Database Format Specification (see https://clang.llvm.org/docs/JSONCompilationDatabase.html).
A Handler is an abstract base class for a class that translates AST nodes from a raw ast type, usually supplied by a language parser into our generic CPG nodes.
This functional interface specifies how a handler class should translate raw AST nodes into CPG nodes.
A language trait, that specifies that this language has an "anonymous" identifier, used for unused parameters or suppressed assignments.
A common super-class for all language traits that arise because they are an ambiguity of a function call, e.g., function-style casts. This means that we cannot differentiate between a CallExpression and other expressions during the frontend and we need to invoke the ResolveCallExpressionAmbiguityPass to resolve this.
A language trait that specifies if the language has the concept of "classes". The alternative is to use structs. Note that some languages can have both and that in some languages structs and classes are essentially the same. This is mostly used to determine if an inferred record declaration can be a class or must be a struct.
A language trait that specifies, that this language has support for default arguments, e.g. in functions.
A language trait, that specifies that this language has "elaborated type specifiers". If so, we should consider them when parsing the types.
A language trait, that specifies that this language treats functions "first-class citizens", meaning they can be assigned to variables and passed as arguments to other functions.
A language trait that specifies that this language allowed overloading functions, meaning that multiple functions can share the same name with different parameters.
A language trait that specifies if the language supports function pointers.
A language trait, that specifies that the language has so-called functional style casts, meaning that they look like regular call expressions. Since we can therefore not distinguish between a CallExpression and a CastExpression, we need to employ an additional pass (ResolveCallExpressionAmbiguityPass) after the initial language frontends are done.
A language trait, that specifies that the language has functional style (object) construction, meaning that constructor calls look like regular call expressions (usually meaning that the language has no dedicated new keyword).
A language trait, that specifies that this language has support for templates or generics.
A language trait, that specifies that this language has global variables directly in the GlobalScope, i.e., not within a namespace, but directly contained in a TranslationUnitDeclaration.
A language trait, that specifies that this language has support for implicit receiver, e.g., that one can omit references to a base such as this.
A language trait that specifies that this language allows overloading of operators.
A language trait, that specifies that this language has certain qualifiers. If so, we should consider them when parsing the types.
A language trait, that specifies that this language has binary operators that will short-circuit evaluation if the logical result is already known: '&&', '||' in Java or 'and','or' in Python
A language trait that specifies if the language has the concept of "structs". The alternative is to use classes. Note that some languages can have both and that in some languages structs and classes are essentially the same. This is mostly used to determine if an inferred record declaration can be a struct or must be a class.
A language trait, that specifies that this language has support for superclasses. If so, we should consider the specified superclass keyword to resolve calls etc.
A language trait, that specifies that this language has support for templates or generics.
A language trait, that specifies that this language has specifiers which let us conclude that we do not know the type. If so, we should consider them when parsing the types.
Represents a programming language. When creating new languages in the CPG, one must derive custom class from this and override the necessary fields and methods.
The main task of the language frontend is to translate the programming language-specific files to the common CPG nodes. It further fills the scopeManager. The language frontend must not be used after having processed the files, i.e., it won't be available in passes.
A language trait is a feature or trait that is common to a group of programming languages. Any Language that supports them should implement the desired trait interface. Examples could be the support of pointers, support for templates or generics.
This class is a piece of legacy code that seems to offer a functionality to register certain listeners that get executed when raw AST nodes are processed into certain nodes (specified in interestingStatements).
Determines if the LanguageFrontend can parse multiple files in parallel. Defaults to true.
A generic exception that can be thrown from a LanguageFrontend, if it reaches a state where it cannot continue translating source code into the graph.
Properties
Checks whether the name for a function (as CharSequence) is a known operator name.