fix(extract): string-dispatch CALLS edges never emitted — detection was in dead code

[isc-tdyar]

String-dispatch CALLS edges never emitted — detection was in dead code

Discovered while indexing a Python codebase that uses string-literal method dispatch — calls of the form:

obj.classMethodValue('some.module.Class', 'MethodName', arg1, arg2)

where the class and method are passed as string literals rather than referenced directly. These produced no CALLS edge in the graph. The callee appeared as an anonymous call with no link to the target.

This pattern appears in Python reflection libraries, plugin systems, and RPC frameworks — any API that takes a class name and method name as strings and dispatches dynamically.

Root cause

The string-dispatch detection existed in walk_calls() in extract_calls.c. But walk_calls is dead code — the pipeline calls cbm_extract_unified() → handle_calls(), never cbm_extract_calls() / walk_calls() directly. The detection logic was never reachable during normal indexing.

Fix

Move the detection into handle_calls(), immediately after the standard CALLS edge is pushed. When a Python call's callee name ends in one of the four dispatch suffixes (.classMethodValue, .classMethodVoid, .classMethodBoolean, .classMethodObject) and both string-literal arguments can be extracted, emit a synthetic CALLS edge to Arg0.Arg1.

Also adds extract_nth_string_arg() — a small helper to extract the N-th string-literal positional argument from an argument list node.

The suffix list is easily extended for other APIs that follow the same shape.

Regression test

python_iris_classMethodValue in tests/test_extraction.c — indexes a minimal Python snippet using .classMethodValue('Pkg.Class', 'Method', ...) and asserts a CALLS edge to Pkg.Class.Method is emitted.

[DeusData]

Thanks for the contribution — and for the clean, signed-off commits. Will review properly when time allows.

One heads-up on CI: everything is green except test-unix (macos-15-intel), and the failure there is not in the test suite (all tests passed) — it's the post-suite parent-death watchdog check (child survived parent death), which has nothing to do with your extraction change. I've rerun the failed job to rule out a runner flake; if it stays red, that's a platform issue on our side and won't be held against this PR.

[isc-tdyar]

Great, thanks!

As a heads-up, I have some actual feature additions in the hopper - I spent time recently adding support for ObjectScript, InterSystems proprietary but well-established language that is tied to our database technology. I will be following the CONTRIBUTING guidelines with an issue submission, but at a high level I propose adding CBM_LANG_OBJECTSCRIPT to lang_specs.c and supporting infrastructure for specifics of that language. I hope this will be something that is viewed as a positive for CBMM, and I am willing to shape it however it can fit within the wider team's conception of "good code" :)

[DeusData]

Thanks @isc-tdyar — moving the string-dispatch detection into the live path is the right call. Two things before merge:

1. The PR adds the detection in handle_calls() but leaves the original unreachable copy in walk_calls() in place — please remove the dead copy (the PR's premise is fixing dead code, so it shouldn't leave a duplicate behind).
2. The dispatch list is IRIS-specific (.classMethodValue, .classMethodVoid, …). Could we generalize this into a small configurable/extensible dispatch table rather than hardcoding one vendor's methods in extract_calls.c? Happy to discuss the shape. 🙏

[isc-tdyar]

Thanks @isc-tdyar — moving the string-dispatch detection into the live path is the right call. Two things before merge:

1. The PR adds the detection in `handle_calls()` but leaves the original unreachable copy in `walk_calls()` in place — please remove the dead copy (the PR's premise is fixing dead code, so it shouldn't leave a duplicate behind).

2. The dispatch list is IRIS-specific (`.classMethodValue`, `.classMethodVoid`, …). Could we generalize this into a small configurable/extensible dispatch table rather than hardcoding one vendor's methods in `extract_calls.c`? Happy to discuss the shape. 🙏

Done — both addressed:

1. Removed walk_calls() and cbm_extract_calls() entirely (including the declaration in cbm.h) — they had no callers in src/ and the unified handle_calls() path supersedes them.
2. Moved the dispatch suffixes out of the inline static array and into a new string_dispatch_suffixes field on CBMLangSpec. Python's row gets py_string_dispatch_suffixes[] (the four .classMethod* names); all other languages implicitly get NULL via C designated initializers — no other rows needed updating. The detection in handle_calls() now reads spec->string_dispatch_suffixes rather than a hardcoded IRIS-specific list.

Rebased onto current main and force-pushed.