fix(elixir): populate first_string_arg for Elixir calls

[henry-hz]

The bug

tree-sitter-elixir attaches no field name to a call's arguments node. Its entire field set is:

key, left, operand, operator, quoted_start, quoted_end, right, target, value

There is no arguments field. But handle_calls() in internal/cbm/extract_calls.c reads exactly that:

TSNode args = ts_node_child_by_field_name(node, TS_FIELD("arguments"));

For Elixir this is always null, so call.first_string_arg was never populated for any Elixir call — not once, in any file. Nothing errored; the field was simply always NULL.

Why it matters

Everything downstream that keys off a call's string argument was silently dead for Elixir:

• Phoenix route paths — get "/wallets", WalletController, :index never yielded a path
• HTTP / async service URLs — the CBM_SVC_HTTP / CBM_SVC_ASYNC classification needs the URL or topic literal
• Config keys — Application.get_env("...") is matched as CBM_SVC_CONFIG, which reads the same field

The fix

The definition side has always known about this. extract_defs.c carries elixir_call_args() with a positional second-child fallback for precisely this reason:

static TSNode elixir_call_args(TSNode node) {
    TSNode args = ts_node_child_by_field_name(node, TS_FIELD("arguments"));
    if (ts_node_is_null(args) && ts_node_child_count(node) > SECOND_CHILD_IDX) {
        args = ts_node_child(node, SECOND_CHILD_IDX);
    }
    return args;
}

This adds the same fallback on the call side. It is gated to call nodes, because Elixir's other call kinds — dot, and the |> binary_operator — carry no arguments node in that position and would otherwise pick up the operator token.

Test

elixir_call_string_argument pins first_string_arg directly rather than asserting a downstream effect, so it stays meaningful independently of route or service classification.

Verification

• make -f Makefile.cbm test-focused TEST_SUITES="extraction registry lang_contract grammar_regression grammar_labels repro_language_registry repro_call_node_manifest" → 388 passed, 0 failed
• The CALLS-breadth contract across 53 languages is unaffected (0 failures); the change is gated to CBM_LANG_ELIXIR
• clang-format --dry-run --Werror clean on the changed source. tests/ was deliberately left unformatted, per the note that it is not in LINT_SRCS
• Exercised end-to-end against elixir-plug/plug and an 829-file Phoenix application

Scope

Submitted as a bug fix under the CONTRIBUTING exception for focused bug fixes and test additions, so there is no prior issue. Additions only — 54 lines, no deletions, no reformatting.

This is the first of four independent Elixir fixes found while auditing Elixir extraction against a real Phoenix codebase. The other three are prepared and gated separately, and I will open them one at a time rather than as a bundle:

1. this PR — first_string_arg never populated
2. Phoenix channel extraction is unreachable in both branches (arguments field again, plus a dispatch on a def node type the grammar does not have)
3. Phoenix router macros mint no Route nodes (every route_reg_suffixes entry is prefixed . or ::, but the macros are bare) — depends on this PR for the path argument
4. Elixir functions carry no complexity, fingerprint or line count

Happy to reorder, split further, or drop any of them if you would rather discuss the approach in an issue first.

🤖 Generated with Claude Code

https://claude.ai/code/session_01DpDDX9sFC16mQ9U9wQ3WNd

[github-actions]

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

• It will not be closed for inactivity. No stale bot touches pull requests here.
• It may still sit a while before a human reads it. That is on us, not on you.
• Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

• Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
• Get CI green, or say which failures you believe are pre-existing.
• Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
• Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.

[henry-hz]

test / test-windows-guards is red here, and I do not believe it is this change. Recording the evidence rather than just asserting it.

The build step succeeded; the guard script failed:

SETUP FAIL: permanent daemon did not start for the crash check
RED (tests/windows/test_daemon_stability.py): section_crash_recovery failed
REGRESSION: 1 green guard(s) went red: tests\windows\test_daemon_stability.py

section_crash_recovery never reached an assertion — it timed out at daemon start (60s budget) before the kill/recover sequence began. Four other guards in the same job also failed preconditions in that run:

• test_hook_augment.py — "SETUP FAIL: index did not run"
• test_cli_non_ascii_arg.py — "SETUP FAIL: ASCII control did not index via CLI"
• test_ui_drive_listing.py — "HTTP server did not start on port 53503"

Five independent subprocess/daemon startups failing in one Windows job reads like a sick runner rather than a code defect.

Why it should not be reachable from this diff:

• tests/windows/test_daemon_stability.py contains no Elixir
• the change is 54 added lines, all inside if (ctx->language == CBM_LANG_ELIXIR), altering only how a call's arguments node is located during extraction
• it touches no process startup, IPC, socket, or path code

Everything else on the PR is green: DCO, lint, lint-mem, codeql-gate, security-static, license-gate, all test-unix shards (ubuntu ×3, ubuntu-arm ×3, macos-14, macos-15-intel), all three test-tsan variants, test-lsan-macos, test-package-wrappers, and pr-smoke on all three platforms.

I do not have rerun rights on this repo — could a maintainer re-run that single job? Happy to push an empty commit to re-trigger instead if you would rather not spend the click, and equally happy to dig further if you have seen this guard fail for a real reason before.

[henry-hz]

Context for this change now lives in #1729, which lays out four Elixir extraction defects found while auditing against a real Phoenix application, and how they relate to the #1239 / docs/elixir-lsp/PLAN.md workstream. This PR is defect 1 of 4.

Refs #1729

[DeusData]

Reran the Windows guard job for you — and you were right that it is not your diff, so let me give you the mechanism rather than just agreeing.

tests/windows/test_daemon_stability.py is a known Windows-only flake. The harness kills daemons with taskkill /F, and on Windows a hard kill leaves the process's byte-range locks held until the OS reclaims them "as resources allow" — not promptly and not deterministically. The next client to start hits ERROR_LOCK_VIOLATION, reads it as BUSY, and is refused. That is why you saw five independent daemon/subprocess setup failures in one job, why it is always Windows, and why a three-line README PR has been seen failing the same guard. #1772 is the fix in flight: it waits out a held startup transition instead of giving up at a fixed deadline. Your reading of "sick runner" was the correct diagnosis from the outside.

The change itself is right, and the test is the good kind. What I want to credit specifically is ASSERT_EQ(1, seen) at the end. Without it, ASSERT_NOT_NULL(first_string_arg) inside a loop passes vacuously if the call is never extracted at all — the failure mode where a green test proves nothing. You closed that yourself. This project has been bitten by exactly that shape before, and a contributor who guards against it unprompted saves a reviewer the archaeology.

I verified your premise too: elixir_call_args() at extract_defs.c:5067 really does apply the positional fallback, so the definition side has always done this and the call side simply never did. The gate is tight — ts_node_is_null(args) && ctx->language == CBM_LANG_ELIXIR && strcmp(ts_node_type(node), "call") == 0 cannot reach another language, and it sits ahead of the ObjectScript fallback without disturbing it.

Two things before I merge:

1. A stale comment. The new comment says cbm_elixir_call_args is the shared second-child fallback — that symbol does not exist anywhere in the tree. Your actual function is elixir_call_arguments_fallback, and the pre-existing one is elixir_call_args. It looks like a shared-helper design that got inlined per-file; the comment would send the next reader looking for something that was never written.

2. A question rather than a request, because it spans your three PRs. With fix(elixir): Phoenix channel extraction is unreachable in both branches #1730 also in flight there would be three near-identical positional-args helpers: elixir_call_args (extract_defs.c), your new elixir_call_arguments_fallback (here), and elixir_channel_call_args (fix(elixir): Phoenix channel extraction is unreachable in both branches #1730). The stale comment suggests you originally intended one shared helper. Would you rather land these as-is and consolidate in a follow-up, or hoist a single helper now? I have no strong preference — three copies of six lines is not a crisis — but you clearly thought about it once and I would rather ask than pick for you.

On your ordering question: yes, #1721 first. Nothing forces it, but your unopened defect 3 (Phoenix router macros minting no Route nodes) depends on the path argument this PR provides, so it is the natural root.

One heads-up that affects all three. Your production files are genuinely disjoint — extract_calls.c, extract_channels.c, extract_defs.c — so nothing here can break anything there. But all three insert into tests/test_extraction.c at the same two anchors: immediately after TEST(elixir_function) closes, and immediately after RUN_TEST(elixir_function); in the suite. GitHub reports all three MERGEABLE because it compares each against main in isolation. I expect the first merge to flip the other two to CONFLICTING at both anchors. It is a trivial rebase, just not a surprise worth having.

Thank you for the tracking issue and for splitting this into four reviewable pieces instead of one large one — that is exactly how I would want a language's defects to arrive.

[DeusData]

Closing the loop: the Windows startup-coordination fix has merged as 7b6363d0 (#1772). That is the fix for the byte-range-lock flake you hit — the daemon now waits out a held startup transition instead of giving up at a fixed deadline.

Notably it merged with test / test-windows-guards green, which is the job that had been flaking. Future runs on your branch should stop showing it once you pick up current main. Thank you for reporting it precisely rather than just re-running.