Important changes to the KAST API in version 10.0

We're constantly improving the KAST API. Unfortunately, sometimes these improvements are not always backwards compatible with your existing custom KAST checkers. The following table describes the changes we've made to the KAST API for 10.0 as well as a description of the changes that you should make to your own custom checkers:

API Member What changed What you need to do...
QualifiedName A QualifiedName node without a qualifier is no longer created. Previously even if a node had no qualifier, it was represented by a QualifiedName node with a child link to a given UnqualifiedName node. A new supertype (AnyName) was introduced for QualifiedName and all UnqualifiedName objects. If your checker expected a node of type QualifiedName with no qualifier, make it accept a node of type AnyName instead.
Op The Op node has been removed entirely. The Op node was previously used to store the operation code for various kinds of expressions (e.g. KTC_OPCODE_ASSIGN, etc.). A new attribute entitled Op has been added to the MemberExpr, UnaryExpr, BinaryExpr and OpFunc node types, and this new attribute now reflects that same operation code. Either check the @Op attribute on the expression node explicitly, or (better) call the new built-in function getOperationCode. For custom functions, use ktc_getOperation.
MemberFunc Previously, MemberFunc nodes contained a "child" FuncDef node that did all the work. This has been modified so that MemberFunc now contains all of the attributes and descendants of FuncDef directly, and no longer contains the FuncDef node as a child. To keep the same functionality, modify your checker to make it catch MemberFunc nodes as well as FuncDef where appropriate.
InitDeclarator When no explicit initializer is present, the InitDeclarator node is no longer created. Properly initialized declarations are now represented by the InitialzedDeclarator node, so KAST patterns concerned with such declarations should be modified accordingly. The common supertype, AnyDeclarator can be used to find either initialized or uninitialized declarations.
Declarator The Declarator node has been removed. The purpose of this node type was to store information about pointers and references in pointer/reference declarations. For pointer/reference declarators specifically, use the new node type PtrDeclarator, which shares a common supertype, AnyDeclarator , with other similar node types.
MemberDeclarator The family of MemberDeclarator types has been removed. Use generic declarators (i.e. the AnyDeclarator supertype) anywhere in place of explicit MemberDeclarator nodes. For bit field declarations you can use the new BitFieldDeclarator node. Note that related to this change, the descendant node type MemberDeclarators has been renamed to Declarators.
DirectDeclarator DirectDeclarator was renamed to NameDeclarator and became a part of the AnyDeclarator supertype. Use generic declarators in any case where DirectDeclarator is currently used. The AnyDirectDeclarator and NoDirectDeclarator types are also removed as a part of this change.
DirectNewDeclarator The DirectNewDeclarator type family has been removed. DirectNewDeclarator was used for representing "new" constructs containing a number of allocated elements ("new int[5]"). Use generic declarators (in particular, ArrayDeclarator). All the NewDeclarator types have also been removed.
NewTypeId All NewTypeId types have been removed. The difference between these types and generic TypeId types was the link to NewDeclarator instead of a link to a generic declarator. Use TypeId instead of NewTypeId. The AnyTypeId supertype that was shared by both TypeId and NewTypeId has also been removed as part of this change.
ConvTypeId ConvTypeIdhas been removed. Use the generic TypeId node instead.
MaybeDeclarator Child node MaybeDeclarator of type Exception was renamed to Declarator. The Maybe prefix is now reserved solely for use in supertypes, no concrete nodes should ever have that prefix.
@Id The Id attribute was removed from nodes Dtor, IdExpr, NameDeclarator, NameSpec and TypeName. Each of these nodes has a child of type AnyName or UnqualifiedName. You can obtain the identifier previously stored in this attribute by querying those descendant name types instead. However, using direct access to a node's attributes is usually not a good practice and KAST developers should use built-in (or custom) functions instead. The getName built-in function can be used for this purpose.