Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#2,581 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
go, typescript
Domain
devtools

Research direction

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.

Written by the indexing model from the issue text.

Description

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.
Dominant language
C
Stars
73.2k
Forks
4.7k
Avg merge
2h 16m
Merged PRs (30d)
423

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from colbymchenry/codegraph

All issues in colbymchenry/codegraph

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.