fix(extract): Go — `import "C"` (cgo pseudo-package) resolves to an arbitrary project symbol named C

[ilyabrykau-orca]

fix(extract): Go — import "C" (cgo pseudo-package) resolves to an arbitrary project symbol named C

Status: fix open — PR #1931 (drop the spec in parse_go_import_spec() when the path is exactly "C"). Measured: 27 false IMPORTS edges → 0. The general non-cgo case of the same mechanism is #1934/#1938.

What happens

import "C" is not an import — "C" is reserved by go/build; no such package can exist. The clause only marks the preceding comment block as C. cbm's Go import parser keeps it as an ordinary spec; it fails Strategies 1–2 in cbm_pipeline_resolve_import_node() and lands in Strategy 3's symbol-name fallback (pass_pkgmap.c), which returns the lexicographically smallest project symbol named C.

Damage measured (~1150-file Go+C repo)

27 files carry import "C" → 27 bogus IMPORTS edges (100%), all converging on one unrelated C member of a test helper. The winner is a lexicographic tie-break, so which symbol gets hijacked changes as the repo grows.

Minimal reproduction

fx/cgo_use.go:

package fx

/*
static int helper(int a) { return a + 1; }
*/
import "C"

func Run(a int) int { return int(C.helper(C.int(a))) }

fx/sub/chan_holder.go:

package sub

type C struct{ N int } // ordinary project symbol that happens to be named C

func NewC() *C { return &C{} }

Before: IMPORTS edge cgo_use.go → sub.C. After: no rows.

Detection recipe

SELECT count(*) FROM edges
WHERE type = 'IMPORTS' AND json_extract(properties, '$.local_name') = 'C';

Nonzero on a cgo repo = this bug.

Fix + test

Skip the "C" spec before it is pushed — Go-specific knowledge belongs in the Go import parser, not the language-agnostic resolver. Reproduce-first test go_cgo_pseudo_import_dropped (RED without the change; also pins that the file's real fmt import survives).

Related: #1934 (general Go import→symbol case), #1929 (cgo modelling), #725; tracked in #1932.