fix(extract): drop cgo's import "C" pseudo-package

[ilyabrykau-orca]

Fixes #1926

Problem

import "C" is not an import. "C" is reserved by go/build; no package with that
import path can exist. The clause only tells the Go toolchain to compile the
immediately preceding comment block as C.

The Go import parser treats it as an ordinary import spec, so every cgo file's
import list — and therefore the per-file import map that call resolution
consults — carries a package that cannot exist. Dropping it at extraction is the
fix: Go-specific knowledge belongs in the Go import parser rather than in the
language-agnostic resolver.

History: the false-edge symptom this PR originally led with

When #1926 was filed (2026-08-30), the pseudo-import also produced false IMPORTS
edges: it fell through Strategies 1 and 2 and landed in the Strategy 3 symbol-name
fallback (src/pipeline/pass_pkgmap.c), which bound all 27 cgo files of the
measured Go+C repository to the same unrelated C member of a test helper.

That measurement predates 7d76b88f ("fix(pipeline): never bind a Go import to
a symbol", merged 2026-08-31 via #1938), which gates Strategy 3 off for Go entirely.
Re-measured on current main (8972ea69) against the same repository — which now
carries 54 import "C" files: IMPORTS edges with target C (by node name or
by local_name/module property): 0. The Go IMPORTS target histogram is
100% Folder (2,303 edges). The false edges are gone exactly as the Strategy-3
gating predicts, so this PR no longer removes any edge; its effect is confined to
the extraction layer.

Change

internal/cbm/extract_imports.c, parse_go_import_spec() — skip the spec when the
import path is exactly "C", before the import is pushed. The guard cannot lose a
real import: go/build reserves the path, so no resolvable package can ever be
spelled "C".

Effect on current main

• The file's import list, and the per-file import map derived from it, no longer
  name a package that cannot exist — so import-closure reasoning (e.g. the
  penalty logic in unique_name resolution) never consults a phantom package.
• Graph shape is unchanged: the repository-level IMPORTS count with target C
  is 0 both before and after this change on current main; the pre-fix(pipeline): never bind a Go import to a symbol #1938 history
  above is what the original description measured.

Test

tests/test_extraction.c — go_cgo_pseudo_import_dropped.

Reproduce-first (extraction-level, so it stays RED-capable regardless of the
resolver gating): RED without the extractor change —

go_cgo_pseudo_import_dropped   FAIL tests/test_extraction.c:2881:
  ASSERT(strcmp(r->imports.items[i].module_path, "C") != 0)
  318 passed, 1 failed

GREEN with it — 319 passed.

The test also asserts the same file's real fmt import survives, so the fix cannot
regress into dropping the whole import block.

Checks

• scripts/test.sh --suites extraction — 319 passed, 0 failed.
• clang-format clean on both edited hunks.
• scripts/lint.sh could not complete locally: clang-tidy and cppcheck are not
  installed on this machine. Relying on CI for those two legs.

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

[DeusData]

Heads-up: this went red-to-merge because #1937 (fcd8bfc1) and #1940 (61de19bb) landed, not because of anything you changed.

Checked with git merge-tree against current main: the conflict is exactly one file, tests/test_extraction.c, and it is insertion-anchor drift — #1940 added its Go struct-field extraction test there. Every source file in your diff auto-merges cleanly.

Re-anchor your test and its RUN_TEST line and the rebase is done. Ping when it is up.

[ilyabrykau-orca]

Rebased onto current main — as your merge-tree note predicted, the only conflict was test insertion-anchor drift (tests/test_extraction.c), re-anchored. Full scripts/test.sh on the rebased head: 7782 passed, 1 failed — the failure is test_daemon_runtime's marker_published assert, a load-timing flake from running three suites concurrently on this machine; it passes solo (47/47) and is unreachable from this diff (extract_imports only).

[DeusData]

This is green and clean, and I was about to merge it — then checked the mechanism and stopped. I think the headline symptom may already be fixed, and I would rather ask than land it on a premise that has moved.

The question

Your description routes the bug through Strategy 3:

fell through Strategy 1 … and Strategy 2 …, and landed in the Strategy 3 symbol-name fallback (pass_pkgmap.c:1904-1998) … all 27 files carrying import "C" pointed their IMPORTS edge at the same unrelated C member of a test helper

But pass_pkgmap.c now has:

bool cbm_import_symbol_fallback_allowed(CBMLanguage lang) {
    return lang != CBM_LANG_GO;
}

introduced by 7d76b88f ("fix(pipeline): never bind a Go import to a symbol", 30 August) — whose comment describes exactly your failure mode, down to the example: "the fallback instead bound the last path segment to an arbitrary same-named project symbol (import "os/exec" → a test harness's exec() method)".

And 7d76b88f is already an ancestor of this PR's head. So on your own branch, Strategy 3 should never run for Go: import "C" misses Strategy 1, misses Strategy 2, and is then skipped rather than falling through — producing no edge at all.

If that reading is right, the 27 false IMPORTS edges are already gone, and this change no longer removes them.

Was the 27-file measurement taken before 7d76b88f landed? That is the one fact I cannot determine from here, and it decides how this PR should be described.

Why I still think it has value

Even with the fallback disabled, parse_go_import_spec() still pushes "C" into the file's import list — so the pseudo-package remains in the import map that call resolution consults. Your description already names that as a separate benefit:

dropping it at extraction also keeps the pseudo-package out of the file's import map used by call resolution

That effect is untouched by 7d76b88f, because that change gates edge resolution, not extraction. So the fix looks correct and worth having — but for the import-map reason, not the false-edge reason.

The guard itself is right regardless. "C" is reserved by go/build and no package with that import path can exist, so dropping it at the Go parser cannot lose a real import — this is a Go language fact, not a heuristic. Putting Go-specific knowledge in the Go import parser rather than the language-agnostic resolver is also the right layer.

What I need

Please confirm whether the 27-edge measurement predates 7d76b88f, and if so update the description to lead with the import-map effect. If you re-measure on current main and the false edges are still there, tell me — that would mean I have misread the gating, and it is the more interesting outcome.

Not blocking on anything else: 34 checks green, CLEAN, and I have cleared the current head.

[ilyabrykau-orca]

Confirmed: the 27-edge measurement predates 7d76b88f. It was taken for #1926, filed 2026-08-30, one day before #1938 merged the Strategy-3 gate. Your reading of the gating is right, not misread.

Re-measured today on current main (8972ea69), same repository (which has since grown to 54 import "C" files):

• IMPORTS edges from .go files with target node named C: 0
• IMPORTS edges with local_name/module property 'C': 0
• Go IMPORTS target-label histogram: Folder 2,303 — nothing else

So the false edges are already gone on main, exactly as the gate predicts, and this PR removes none. I have rewritten the description to lead with the import-map effect: the extractor still pushes "C" into the file's import list, so the per-file import map that call resolution consults names a package that cannot exist; this PR stops that at the parser, where the go/build reservation makes the skip a language fact rather than a heuristic. The original 27-edge story is kept as history with the predates-7d76b88f note.

The RED/GREEN evidence is unaffected — the reproduce-first test asserts at extraction level (r->imports.items[i].module_path), which stays RED-capable regardless of resolver gating.