Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#2,581 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
go, typescript
Ambito
devtools

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.
Lingua principale
C
Stelle
73.2k
Fork
4.7k
Merge medio
4h 46m
PR unite (30g)
478

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di colbymchenry/codegraph

Tutte le issue di colbymchenry/codegraph

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.