Go: three smaller call-edge inaccuracies (type conversions, external test packages, build tags)

Start with the three reproductions in the issue and the calls edges they produce, then read matchByExactName and findBestMatch in src/resolution/name-matcher.ts (around lines 7970-8003) and isRustGoCallTarget (around line 5238). Case 1 needs a decision between re-kinding the edge and dropping it, and case 3 needs a decision on keeping both edges or one. Done means each of the three Go modules yields the expected edges when indexed with codegraph init -i.

Summary

Three low-severity Go shapes where a calls edge is recorded that the source does not make, or goes to the wrong one of two definitions. Each one came up while checking edges in a real 284-file Go module. They are filed together because each is small. They have different causes.

1. A type conversion Category(s), with type Category string, is recorded as a calls edge to the type.
2. A call in an external test package (package a_test) binds to the package a test helper of the same name, not to the a_test helper in the same directory.
3. A function defined twice under complementary build constraints (//go:build unix / //go:build !unix) gets one edge, always to the !unix file, including on Linux.

Reproduction (verified)

On main at 8fe31569, built from source, Linux (WSL2), Node 22.23.2, Go 1.26, WASM extractor (CODEGRAPH_KERNEL=0). Each case is its own module with go 1.22 in go.mod, and each passes go vet (case 3 also passes with GOOS=windows). Command: codegraph init -i. Then calls edges from the SQLite index, excluding main as the source, as source file:line, source, target kind, target, target file:line, resolvedBy.

1. Type conversion recorded as a call

package main

type Category string

func use(s string) Category {
	return Category(s) // a conversion, not a call
}

func main() { use("") }

Observed:

main.go:6 use -> type_alias Category main.go:3 (exact-match)

Expected: no calls edge. If a dependency on the type is wanted, a references edge to Category would describe it.

2. External test package binds the internal package's helper

// a.go
package a

func Real() {}

// a_internal_test.go
package a

import "testing"

func corpus(t *testing.T) []string { return nil }

func TestInternal(t *testing.T) { _ = corpus(t) }

// b_ext_helpers_test.go
package a_test

import "testing"

func corpus(t *testing.T, root string) []string { return nil }

// a_ext_test.go
package a_test

import "testing"

func TestExt(t *testing.T) { _ = corpus(t, "") }

Observed:

a_ext_test.go:5      TestExt      -> function corpus a_internal_test.go:5 (exact-match)
a_internal_test.go:7 TestInternal -> function corpus a_internal_test.go:5 (exact-match)

Expected: TestExt -> corpus in b_ext_helpers_test.go:5. package a and package a_test are different packages, so the package a helper is not visible from a_ext_test.go at all. The second edge is correct.

3. Build-constrained definitions: one edge, to the non-host file

// main.go
package main

func main() { println(sep()) }

// sep_unix.go
//go:build unix

package main

func sep() string { return "/" }

// sep_other.go
//go:build !unix

package main

func sep() string { return "\\" }

Observed, the same on three fresh indexes:

main.go:3 main -> function sep sep_other.go:5 (exact-match)

Both sep nodes are indexed. Expected: an edge to each definition, since either one can be the callee depending on the build. If only one edge is kept, it should not be chosen arbitrarily. Today the !unix variant is the only callee shown, on a Linux machine. Impact and callers for sep_unix.go::sep show nothing.

Likely cause (inferred from reading the code)

I traced each edge with an instrumented build of the same source. The edges are returned by matchByExactName: case 1 by its single-candidate branch (name-matcher.ts#L7970-L7980), and cases 2 and 3 by findBestMatch (L7991-L8003). The rest comes from reading the code:

1. Conversion. A bare Go call keeps every non-method candidate (isRustGoCallTarget, L5238), and that includes type nodes. In Go, a calls ref whose target is a type is a conversion, so it could be re-kinded or dropped. #2543's proposed fix explicitly preserves same-package conversions resolving to the type, so changing the edge kind may be preferable to dropping the resolution.
2. External test package. Both helpers are in the same directory and the same language, so findBestMatch's scoring (L15644) does not separate them, and the tie goes to candidate order. I found no code under src/ that reads a Go file's package clause, so a and a_test are treated as one package.
3. Build tags. Same scoring tie as case 2, and I found no code under src/ that reads //go:build lines.

Related

• #2543: another Go shape where findBestMatch breaks a tie between same-named definitions on proximity alone (methods there).
• #2408 (merged): a bare Go type name links its own package's type, not one elsewhere. That one is about package visibility across directories, not within one directory.
• #1954 (open) handles conversions as a source of a receiver's type (list := model.BotList(bots)), not the edge the conversion itself records.

Not checked

• The native kernel (CODEGRAPH_KERNEL unset).
• A conversion to a struct type, a pointer type ((*T)(p)) or a generic type. The Go framework resolver may produce instantiates for some of these.
• An external test package that also imports the package under test and calls a.corpus. That should be unaffected, because the qualified-name path handles it.
• Filename-only constraints (sep_windows.go with no //go:build line), and the legacy // +build form.