mirror of
https://github.com/colbymchenry/codegraph.git
synced 2026-10-29 07:44:09 +08:00
Colby MchenryandClaude Opus 4.8
a164ceae8b
* fix(extraction): recognize common third-party C++ inline macros, not just UE Extend blankCppInlineMacros beyond Unreal Engine's FORCEINLINE family to the inline/linkage macros that vendored third-party libraries define and that mangle function names the same way: - pugixml: PUGI__FN / PUGI__FN_NO_INLINE (before the return type) and PUGIXML_FUNCTION (linkage macro, between return type and name — the blank mechanism handles both positions). - Godot: _FORCE_INLINE_ / _ALWAYS_INLINE_. - Boost: BOOST_FORCEINLINE / BOOST_NOINLINE. - Generic cross-ecosystem hints: ALWAYS_INLINE / FORCE_INLINE / NOINLINE. The list now drives a single generated alternation (longest-token-first), so adding a codebase's macro is a one-line change. Still curated exact tokens in specifier position only — a real all-caps return type like `HRESULT DoIt()` is never touched (verified by controls). Validated on CARLA (large UE project, 1131 C++/h files): function-name mangles 440 -> 16 (428 fixed). The 16 residual and 7 clean->mangled shifts are all in third-party vendored files — chiefly pugixml.cpp, a 12k-line macro amalgamation where error recovery is non-local, so blanking one of several *stacked* macros (PUGI__FN + PUGI__UNSIGNED_OVERFLOW …) shifts an already-imperfect extraction. Normal C++/UE code (ActionRoguelike, ALS) sees zero regressions — blanking a macro there only helps. Chasing pugixml's internal attribute macros is left out of scope. Seven regression tests added. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * docs(changelog): note third-party C++ inline macro recognition (#1101) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>