A Go import path names a package - never a function, method, field or
another language's build target. Strategy 1 resolves every correct Go
import (module path -> the package's Folder node); when it misses the
import is external and the correct result is NO edge. Two name-guess
fallbacks violated that:
- Strategy 3's language-agnostic symbol-name fallback matched the
path's last segment against any project definition of the same
simple name and returned the lexicographically smallest survivor:
import "os/exec" bound a test harness's exec() method (52 edges on
the measured repo), two imports bound a Function extracted from a
Makefile. 89 of 2295 Go IMPORTS edges (3.9%) were false; 27 of those
are the import "C" case (#1926/#1931), the remaining 62 this.
- Strategy 1b's sibling-file resolution admits symbol labels through
import_targetable_label, re-creating the same bug one directory
closer: with Strategy 3 gated, the field census still bound one
os/exec import to a same-package exec() method.
Gate both on the importing file's language through a new pure
predicate, cbm_import_symbol_fallback_allowed(): false for Go, true
for everything else - member-importing languages (Python, Java, Rust
use crate::ops::helper) legitimately need the symbol fallback, and
build/markup grammars (SCSS partials, Meson subdir, Pony use) the
sibling one. Strategies 1, 2 and 4 are untouched.
Reproduce-first test ei_go_import_never_binds_symbol asserts the
IMPORTS relation EXACTLY (an internal package import stays; neither
the cross-package nor the same-package decoy may be bound): RED
count=2 expected==1 before each gate, GREEN after. Adds
ei_edge_count_is, the exact-count sibling of ei_edge_present, since a
floor cannot catch a fabricated extra edge.
Field-validated on a real ~1150-file Go+C repo: Go IMPORTS by target
label went Folder 2206 / Method 85 / Function 4 on main to
Folder 2206 / Method 0 / Function 0 with the fix; all 2206 correct
package-Folder edges survive.
Fixes#1934
Signed-off-by: Ilya Brykau <ilya.brykau@orca.security>