fix(extract): give each Go init() its own QN

[ilyabrykau-orca]

What does this PR do?

Fixes #1910. Stacked on #1913 (which stacks on #1907) — same extraction area and shared test scaffolding; review only the last commit.

Go allows any number of init() functions per package — even several in one file — and all of them run at start-up. On the flat QN (proj.pkg.init) they all collided and the graph upsert kept one node per package, silently dropping the rest (measured in #1910: 21 decoder-registration inits in one package → 1 node; 29 in the repo → 7 nodes).

The change, following the #495 Rust cfg-twin pattern (and the #1266 GoogleTest name-derivation precedent):

1. internal/cbm/extract_defs.c — suffix the QN with the file basename and line: proj.pkg.init#a.go:L5. Calling init explicitly is illegal in Go, so nothing ever joins on the plain QN — no resolution path is affected.
2. internal/cbm/extract_unified.c (compute_func_qn) — mirror the exact formula, so init-body calls keep their source attribution instead of degrading to the calls_find_source File-node fallback.

Tests (reproduce-first):

• pipeline_go_multi_init_nodes_survive — two files, one package, one init() each: RED without the def-side change (ic == 1, expected 2), GREEN with it.
• extract_go_multiple_init_disambiguated — two inits in ONE file get distinct suffixed QNs (the line component disambiguates within a file).

Full scripts/test.sh leg green (ASan+UBSan, "All tests passed"); git clang-format --diff clean on changed lines.

Checklist

• Every commit is signed off (git commit -s) — required, CI rejects
  unsigned commits (DCO, see CONTRIBUTING.md)
• Tests pass locally (scripts/test.sh — full leg, ASan+UBSan, "All tests passed")
• Lint passes (git clang-format --diff clean on changed lines; clang-tidy/cppcheck via CI)
• New behavior is covered by a test (reproduce-first for bug fixes)

[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.

[ilyabrykau-orca]

Rebased onto current main (stacked on the rebased #1913). No semantic changes; full test leg green. Post-fix init-node recovery (29/29) is in the #1906 census comment.

[DeusData]

Reviewed the last commit. The diagnosis is right, the safety argument holds, and I have one substantive concern about the suffix itself.

The diagnosis is confirmed by the schema. src/store/store.c:257 declares UNIQUE(project, qualified_name) and the node upsert at :2364 is ON CONFLICT(project, qualified_name) DO UPDATE SET. So a flat proj.pkg.init really does mean every init in a package is the same row, and the last writer wins — which is exactly your 21 → 1.

Your safety claim holds, and I checked it both ways. Nothing in internal/cbm/, the LSP resolvers, or src/pipeline/ matches on the literal "init", so no resolver joins on the plain QN. And since calling init explicitly is illegal in Go, no call site produces init as a callee either. Both directions are clear.

The precedents you cite are real. extract_defs.c:2079 is the Rust cfg twin using "%s#%s", and :3544–:3613 is the GoogleTest derivation, whose comment names the same failure — "causing qualified-name collisions and node loss (#1266)". The shape is established house practice for this problem class.

The concern: the suffix is not stable, and both precedents are

This is the part I would like you to weigh, because it is the one property those two precedents share that yours does not.

The Rust cfg twin derives its suffix from the cfg(...) predicate text, and says why in the code:

Build a compact predicate suffix from the cfg(...) text, dropping whitespace and quotes so the QN stays readable and stable.

GoogleTest derives its from the macro arguments — TEST(Suite, Case) → TEST_Suite_Case. Both are semantic content that does not move when the file is edited.

proj.pkg.init#a.go:L5 embeds a line number. Add an import above that init and its qualified name changes — and since the QN is the node's identity under that UNIQUE constraint, an incremental reindex sees the old node vanish and a new one appear, for an edit that did not touch the function. That is node churn on every unrelated edit above any init, and it lands on the delta-merge path rather than a full rebuild.

The file basename alone will not do it — your own extract_go_multiple_init_disambiguated test requires two inits in one file to differ, and only the line separates them today. But a per-file ordinal would: proj.pkg.init#a.go:1, #a.go:2. That still satisfies that test, and it only churns if you reorder the inits in a file rather than every time you add a line above one.

I am raising this rather than ruling on it — you may have considered ordinals and rejected them for a reason I cannot see from here. If so, say why and I will take it.

Also

The whole stack is currently DIRTY — #1907, #1913 and this one all have conflicts. main was broken for a few hours today (duplicate struct members merged into type_registry.h) and was repaired an hour ago by #1993, so now is a good moment to rebase all three.

Thanks for measuring the loss rather than describing it — "21 decoder-registration inits in one package → 1 node; 29 in the repo → 7 nodes" is what makes this obviously worth fixing.

[ilyabrykau-orca]

Rebased onto current main as part of the 1907→1913→1915→1936 stack; only test insertion-anchor drift in tests/test_pipeline.c, re-anchored. Full scripts/test.sh green on the stack head.

[ilyabrykau-orca]

You are right, and the ordinal is strictly better — implemented, not argued with.

I had not weighed the incremental path when I chose the line number: on a full rebuild the line suffix is merely ugly, but under delta-merge the QN is node identity, so an insertion above any init would delete-and-recreate the node on an edit that never touched it. Both precedents being edit-stable is not a coincidence; it is the property that makes a QN suffix safe.

Now: pkg.init#file.go:N, where N is the 1-based source-order ordinal among the file's top-level init function_declarations. One formula, computed from the tree by a shared cbm_go_init_ordinal (helpers.c) on both the definition side and the call-scope side (compute_func_qn), so the two cannot drift. Reordering the inits within a file still churns — that is inherent to any content-free discriminator — but nothing else does.

The test now pins the property you asked for, not just distinctness: exact QNs t.init#x.go:1 / t.init#x.go:2, then the same file re-extracted with an import and a declaration inserted above both inits, asserting both QNs are byte-identical to before.

Branch force-pushed with the stack rebase; full scripts/test.sh green on the stack head.