Repository navigation
x/tools/gopls: follow linkname references #81462
Description
I propose that gopls's reference tracing (specifically gopls/internal/cache/xrefs) be updated to follow well formed linkname pairs (aka "handshake" linknames, #67401).
gopls version
Build info
--------------
golang.org/x/tools/gopls v0.23.0
golang.org/x/tools/gopls@v0.23.0 h1:Dn6mf9WXu9iLnTftDDMb9wV0c6Se7PjzEMqP0LEe08Y=
github.com/BurntSushi/toml@v1.6.0 h1:dRaEfpa2VI55EwlIW72hMRHdWouJeRF7TPYhI+AUQjk=
github.com/fatih/camelcase@v1.0.0 h1:hxNvNX/xYBp0ovncs8WyWZrOrpBNub/JfaMvbURyft8=
github.com/fatih/gomodifytags@v1.17.1-0.20250423142747-f3939df9aa3c h1:dDSgAjoOMp8da3egfz0t2S+t8RGOpEmEXZubcGuc0Bg=
github.com/fatih/structtag@v1.2.0 h1:/OdNE99OxoI/PqaW/SuSK9uxxT3f/tcSZgon/ssNSx4=
github.com/fsnotify/fsnotify@v1.9.0 h1:2Ml+OJNzbYCTzsxtv8vKSFD9PbJjmhYF14k/jKC7S9k=
github.com/google/jsonschema-go@v0.4.3 h1:/DBOLZTfDow7pe2GmaJNhltueGTtDKICi8V8p+DQPd0=
github.com/modelcontextprotocol/go-sdk@v1.6.0 h1:PPLS3kn7WtOEnR+Af4X5H96SG0qSab8R/ZQT/HkhPkY=
github.com/segmentio/asm@v1.2.1 h1:DTNbBqs57ioxAD4PrArqftgypG4/qNpXoJx8TVXxPR0=
github.com/segmentio/encoding@v0.5.4 h1:OW1VRern8Nw6ITAtwSZ7Idrl3MXCFwXHPgqESYfvNt0=
github.com/yosida95/uritemplate/v3@v3.0.2 h1:Ed3Oyj9yrmi9087+NczuL5BwkIc4wvTb5zIM+UJPGz4=
golang.org/x/exp/typeparams@v0.0.0-20260611194520-c48552f49976 h1:GTD/WuaexTazIG/SxLOz4rEKZPDVilmVVC2nz4xhwfE=
golang.org/x/mod@v0.37.0 h1:vF1DjpVEshcIqoEaauuHebaLk1O1forxjxBaVn884JQ=
golang.org/x/oauth2@v0.36.0 h1:peZ/1z27fi9hUOFCAZaHyrpWG5lwe0RJEEEeH0ThlIs=
golang.org/x/sync@v0.21.0 h1:HLII4xRRTtCRkxYp4HNFF0Js/Og6q2i++KXbg0gHCwM=
golang.org/x/sys@v0.46.0 h1:noSf2Fq6F8DBgS+LysIkx7rIExoNHJsxOAtPp4rthXw=
golang.org/x/telemetry@v0.0.0-20260625142307-59b4966ccb57 h1:nwGZBCt+FnXUrGsj5vjzAsEmkcaFvd82BbOjECiFYZc=
golang.org/x/text@v0.38.0 h1:sXmwo9DwP3OK9EZ7PqAdaooSGozfl/3a6/xJcbzPRhE=
golang.org/x/tools@v0.47.1-0.20260707181000-a299dadba899 h1:5O28oLQxJ1jif5UNdi9OULXCd4g3rsy3xkECh96fnf8=
golang.org/x/vuln@v1.4.0 h1:FpmTZiV4PyqY3lFfuCkz1JftEXb/+8M2NEkjJM5TF4g=
honnef.co/go/tools@v0.8.0-rc.1 h1:wqMm2kjcEXMOr+6yau+pdKqJKe6l2N1aKPkpini+Kzk=
mvdan.cc/gofumpt@v0.10.0 h1:yGGpRS2pBN2OQIi7b21IXknJna7faPkFaVfHLrN6Euo=
mvdan.cc/xurls/v2@v2.6.0 h1:3NTZpeTxYVWNSokW3MKeyVkz/j7uYXYiMtXRUfmjbgI=
go: go1.28-devel_c594198381 Sat Sep 5 05:32:50 2026 -0700
go env
AR='ar'
CC='gcc'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='g++'
GCCGO='gccgo'
GO111MODULE=''
GOAMD64='v1'
GOARCH='amd64'
GOAUTH='netrc'
GOBIN='$HOME/go/bin'
GOCACHE='$HOME/.cache/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='$HOME/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build3688907458=/tmp/go-build -gno-record-gcc-switches'
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMOD='$HOME/src/golang/go/src/go.mod'
GOMODCACHE='$HOME/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPACKAGESDRIVER=''
GOPATH='$HOME/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='$HOME/src/golang/go'
GOSUMDB='sum.golang.org'
GOTELEMETRY='on'
GOTELEMETRYDIR='$HOME/.config/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='$HOME/src/golang/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.28-devel_c594198381 Sat Sep 5 05:32:50 2026 -0700'
GOWORK=''
PKG_CONFIG='pkg-config'What did you do?
Executed "Find all references" on runtime.newTimer (stdlib).
What did you see happen?
No references.
What did you expect to see?
References in the time package.
Editor and settings
No response
Logs
No response
Activity
gabyhelp commentedon Sep 10, 2026
Related Issues
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)
adonovan commentedon Sep 11, 2026
The features sounds reasonable (Hover and Definition already respect //go:linkname annotations). But there may be subtleties in the implementation because, unlike Hover and Definition, which are a pure function of the forward transitive closure, linkname references may be "upwards" or "lateral", which means the implementation has to look at packages outside the transitive closure, which (a) is expensive and (b) violates the axioms of the incremental dependency analysis machinery. So we may be limited in which linkname references we can support.
firelizzard18 commentedon Sep 11, 2026
My specific use-case is exploring the stdlib. I am currently building an understanding of the scheduler, and I was trying to understand "sources of work". I was digging through the reverse call graph when I saw that
runtime.newTimerandruntime.resetTimerhad no callers (according to the call graph). For that purpose, "linknames within the same module" would be sufficient. Though that still might not scale for huge codebases.