v1.2.0

[1.2.0] - 2026-07-02

New Features

• Method calls made through a local variable now resolve to the method in many more languages. When code does const logger = new Logger(); logger.log(); (or the equivalent), CodeGraph infers the local variable's type from its declaration or initializer and links the call to the right method — so these calls now show up in callers, impact/blast-radius, and codegraph_explore flow traces instead of being dropped. Previously only C++ handled this; it now also covers TypeScript, JavaScript, Python, Java, C#, Kotlin, Swift, Go, Rust, Dart, Scala, and PHP. (#1108)
• Ruby method calls made on a receiver (logger.log) now record an edge to the method. Previously the Ruby indexer kept only the receiver and discarded the method name, so a method called through a variable or object had no recorded callers and was missing from impact/blast-radius and flow traces; combined with the local-variable type inference above, logger = Logger.new; logger.log now links to Logger#log. Calls to a class method (Foo.bar) and object construction (Foo.new) are still recorded too. (#1110)
• The same local-variable method-call resolution now extends to Lua, Luau, R, and Pascal/Delphi. A method invoked through a local — Lua/Luau local lg = Logger.new(); lg:log(), R lg <- Logger$new(); lg$log(), or Pascal var lg: TLogger; ... lg.Log — now links to the right method instead of being dropped. (#1112)

Fixes

• Indexing a large project no longer gets killed partway through with a "Main thread unresponsive — killing the wedged process" message. The safety watchdog that stops a genuinely stuck index was mistaking slow-but-normal work for a hang: on a big repo, linking up references and cross-file relationships can legitimately run for a while, and that work now regularly yields so the watchdog can tell real progress from a true stall. Projects that previously failed to finish codegraph init / codegraph index (and had to fall back to CODEGRAPH_NO_WATCHDOG=1) now complete normally, while a genuinely hung process is still caught. Thanks @zmcrazy, @YoungLiao, and @GeeLab-Mob for the reports. (#1091)
• On Windows, a console window no longer briefly flashes when CodeGraph runs as a background MCP server. When the npm launcher started the bundled runtime — which happens every time an editor starts the server or reconnects after the daemon idles out — and during its self-heal step that extracts a missing platform bundle, Windows would pop up a black console (conhost) window for a moment. Both now launch hidden, matching how the daemon already behaved; the browser-open step of codegraph login was hardened the same way. Thanks @luoyerr for the report and root-cause analysis. (#1092)
• C++ forward declarations no longer crowd out the real class definition. A class Foo; forward declaration — common in large C++ and Unreal Engine codebases, where a heavily used class is forward-declared across dozens of headers — was indexed as its own class node every time it appeared. So exploring that class returned mostly forward-declaration sites, and could even pick one of them as the representative for blast-radius, burying the actual definition and its members and callers. Bodiless forward declarations are now skipped for C and C++, exactly as forward-declared structs and enums already were, so only the real definition is indexed. Languages where a class with no body is a complete definition — such as Kotlin's class Empty and Scala — are unaffected. Thanks @luoyxy for the report and root-cause analysis. (#1093)
• C++ methods that return a reference, and user-defined conversion operators, are now indexed under their correct names. An inline getter like const FGameplayTagContainer& GetActiveTags() const — everywhere in Unreal Engine headers — was indexed as & GetActiveTags() const instead of GetActiveTags, and a conversion operator like operator EALSMovementState() const kept its trailing () const instead of reading operator EALSMovementState. In both cases the garbled name meant you couldn't find the symbol by name and its callers weren't linked. Both now read cleanly, matching how pointer-returning and value-returning methods already worked. (#1096)
• C++ functions written with an inline-specifier macro before the return type are now indexed correctly. In Unreal Engine, inline helpers are commonly written FORCEINLINE FString GetEnumerationToString(...); the FORCEINLINE macro made the parser read the return type as part of the function's name (FString GetEnumerationToString instead of GetEnumerationToString) and lose the real return type, so the function couldn't be found by name and its callers weren't linked. CodeGraph now recognizes the standard Unreal inline macros (FORCEINLINE, FORCENOINLINE, FORCEINLINE_DEBUGGABLE), so both the name and the return type are captured. (#1100)
• The same function-name recovery now covers inline macros from common third-party C++ libraries, not just Unreal Engine — including pugixml (PUGI__FN, PUGIXML_FUNCTION), Godot (_FORCE_INLINE_), Boost (BOOST_FORCEINLINE), and generic ALWAYS_INLINE / FORCE_INLINE. Functions decorated with these are now indexed under their real names. On a large Unreal project vendoring these libraries this cleaned up the large majority of remaining function-name garbling. (#1101)
• C++ function names are now recovered even when decorated with a macro CodeGraph doesn't specifically know about. A function written SOME_LIBRARY_MACRO ReturnType doWork(...) previously had the macro or return type absorbed into its name whenever the macro wasn't one CodeGraph recognized; now the real name (doWork) is recovered regardless of the macro, so it's findable and its callers link — no per-library configuration needed. The recognized-macro list was also broadened (Qt, Folly, Abseil, LLVM, V8, Eigen, rapidjson) so those additionally capture the return type. This only ever cleans up an already-garbled name and is limited to C and C++, so ordinary names — and languages like Kotlin and Scala where identifiers can legitimately contain spaces — are unaffected. (#1102)
• The set of C++ libraries whose macros are recognized for full return-type recovery was expanded well beyond Unreal Engine — now spanning Mozilla, Protobuf, {fmt}, nlohmann/json, GLM, Bullet, Skia, OpenCV, EASTL, Cocos2d-x, GLib, SQLite, and the common Windows calling conventions (so HRESULT WINAPI CreateThing(...) indexes as CreateThing returning HRESULT). Functions from libraries not on the list still get their name recovered automatically; being listed additionally recovers the return type. (#1103)
• Graph traversal and blast-radius results no longer drop or miscount relationships in a handful of edge cases. When a symbol could be reached by more than one path, an impact/blast-radius query could leave out a direct dependency between two symbols that were already linked another way; separately, the lower-level graph traversal used by the library API could keep only one of several relationships between the same pair of symbols (for example a symbol that both calls and references another), count a caller reached through two different call sites twice, or return slightly more results than the requested size limit on a very highly-connected symbol. These were long-standing and mostly masked by later de-duplication, so day-to-day query results were largely unaffected, but the traversal now returns the complete, correctly-bounded set. Thanks @inth3shadows for the precise, individually-traced reports. (#1086, #1087, #1088, #1089, #1090)
• Method calls to same-named classes in different files now resolve to the right definition. If two files each declared, say, a Logger class with its own log() method, a call could be linked to whichever definition happened to be indexed first — so a call in one file wrongly pointed at the class in another, mixing up that method's callers and blast radius. This affected calls written as obj.log(), Logger.log(), and Logger::log() across many languages, including C++, Python, TypeScript, Java, C#, and Rust. When a method name is ambiguous, CodeGraph now prefers the definition in the calling file itself — the correct target in the common case — while Java/Kotlin calls that an import already pins to another file are unaffected. Thanks @inth3shadows for the minimal repro and root-cause analysis. (#1079)