Repository navigation
Go: a local or parameter used as a value references a same-named package function #2596
Description
Summary
In Go, using a local or parameter as a value, like apply(run) with a parameter run func(int, int) int, creates a references edge to a package-level func run that shares its name. The local shadows the package function there, so the edge is wrong. This is the value-use half of #2580; the PR for #2580 fixes bare calls only.
Reproduction (verified)
On main at c29caf2, and on the #2580 branch, Linux, Node 22, CODEGRAPH_KERNEL=0:
package main
func run(a, b int) int { return a + b }
func apply(f any) {}
func use(run func(int, int) int) {
apply(run)
}
func main() { use(nil) }codegraph init -i gives use -references-> function:run. A local gives the same: run := 1; _ = run.
Expected: no edge from use to the package run.
Why the #2580 fix doesn't cover it
Dropping a shadowed value ref is not safe as things stand. The extractor records a Go function-value ref once per function and name (flushFnRefCandidates, inferred from reading the code). If the first use in a function is a shadowing local and a later use is the package function, dropping the first ref also loses the later, correct one. A fix needs one ref per use, or a dedupe that keeps a ref per scope.
Related: #2580.
Activity
colbymchenry commentedon Oct 22, 2026
Thanks for the precise write-up. Your two repros were already fixed on
mainby #2658.The case you predicted was real, though. When a function's first use of the name was the shadowing local, a later use of the package function lost its reference too.
#2776 fixes that in both extractors and is merged to
main. A function that binds the name itself now records one use per scope. A use outside the local's scope links to the package function again, and a use the local covers links to nothing. It ships in the next release after 1.6.2.fix(go): a function value keeps its link past a local of the same name (