Full TypeAliasDecl support in ARMOR (TreeBuilder, USR/NSR generation) + unit tests (Release v0.7.4)

[Likith Viswanath Basina (likivisw)]

Summary

This PR implements complete handling of using X = Y type alias declarations (TypeAliasDecl) across the ARMOR API-compatibility pipeline, and adds the CMake wiring and unit test coverage needed to validate it.

Changes

1. Full TypeAliasDecl processing in TreeBuilder

• Changed BuildTypeAliasDecl return type from void to bool so traversal control correctly propagates back to VisitTypeAliasDecl.
• Replaced the previous stub (processUnhandledDecl) with full APINode construction for non-templated type aliases, including qualified name, data/canonical types, USR, NSR, and access specifier.
• Added special-case handling for function pointer type aliases via normalizeFunctionPointerType.
• Templated aliases and aliases nested in templated classes are still skipped early and routed through processUnhandledDecl.
• Added VisitTypeAliasDecl to USRGenerator and NSRGenerator so using X = Y produces the same USR/NSR as an equivalent typedef, keeping identification consistent between the two syntaxes.
• Updated functional test baselines (inactive_code_update, and new complex_chains / type_alias_del_changes / template_changes cases) to reflect the new output.

2. New CMake subdirectories for unit test modules

• Wired up nsr_generator, qualified_name_generator, and usr_generator unit test directories into src/tests/common/CMakeLists.txt.
• Added supporting conftest.py and main.cpp fixtures for each module.
• Added initial ARMOR/LLVM test cases covering overloading (class, struct, union, function, variable), C++ friends, templates, anonymous tags, field/var merging, and core LLVM USR generation (array types, function types, linkage, C++ USR, C++0x USR).

3. Type alias unit tests for the NSR generator

• Added comprehensive unit tests exercising the new type alias handling end-to-end, covering:
  • Primitive type aliases (int, float, char, bool, etc.)
  • Chained primitive aliases (alias of alias of alias)
  • Pointer and reference aliases
  • STL container aliases (vector, map, unordered_map, pair, tuple, array)
  • Chained container aliases (nested alias chains)
  • Template type aliases with various parameter combinations
• Added matching expected-output files validating USR generation and declaration metadata (Kind, Location, Armor USR, Clang USR) for both the NSR and USR generators.

Motivation

using-style type aliases were previously unhandled by the tree builder, causing them to be treated as opaque/unhandled declarations rather than being resolved to their underlying type like typedef. This meant API compatibility checks could miss or misreport changes involving using aliases (including chained aliases, function pointer aliases, and container aliases). This PR closes that gap and backs it with test coverage.

Example: v1/v2 Library Header

The new handling lets typedef and using be freely interchanged across library versions without the diff engine flagging a spurious API break, as long as the resolved type is unchanged. It also still catches a real, semantic change at the end of an alias chain.

v1/mylib.h

// 1. typedef chain in v1
typedef uint32_t      handle_base_t;
typedef handle_base_t handle_mid_t;
typedef handle_mid_t  handle_t;

// 2. Function-pointer typedef
typedef void (*callback_base_fn)(int code, const char *msg);
typedef callback_base_fn callback_t;

// 3. Chain that changes semantically at the base type
typedef int16_t     size_base_t;
typedef size_base_t size_mid_t;
typedef size_mid_t  size_t_alias;

v2/mylib.h

// 1. Same chain, rewritten as `using` — no reported API break.
using handle_base_t = uint32_t;
using handle_mid_t  = handle_base_t;
using handle_t      = handle_mid_t;

// 2. Function-pointer alias, same signature — no reported API break.
using callback_base_fn = void (*)(int code, const char *msg);
using callback_t       = callback_base_fn;

// 3. Alias names untouched, but base type widens int16_t -> int32_t —
//    this IS a real incompatible change and is still correctly detected.
typedef int32_t      size_base_t;
typedef size_base_t  size_mid_t;
typedef size_mid_t   size_t_alias;

Resulting AST (API) diff

Running the compatibility checker on v1 vs v2 above produces:

[
  {
    "nodeType": "Typedef",
    "qualifiedName": "size_base_t",
    "tag": "modified",
    "children": [
      { "nodeType": "Typedef", "qualifiedName": "size_base_t", "dataType": "short", "tag": "removed" },
      { "nodeType": "Typedef", "qualifiedName": "size_base_t", "dataType": "int",   "tag": "added" }
    ]
  }
]

• handle_t / handle_mid_t / handle_base_t and callback_t / callback_base_fn produce no diff entries at all — the typedef → using rewrite is correctly recognized as a no-op, which is exactly the false-positive this change eliminates.
• size_base_t is still correctly reported as modified, since its underlying type actually widened (short → int), regardless of typedef/using spelling.

Testing

• Added/updated functional test suites: complex_chains, type_alias_del_changes, template_changes, inactive_code_update.
• Added new unit test suites under src/tests/common/unit/{nsr_generator,qualified_name_generator,usr_generator} covering type aliases, overloading scenarios, C++ friends, templates, and core USR generation.

Notes

• No behavioral changes to typedef handling — using aliases now converge to the same USR/NSR output for equivalent declarations.
• Templated type aliases remain intentionally unhandled (out of scope for this change).