x/tools: v0.8.0 through v0.25.0 (Oct 2024) contain public packages that fail to build with Go 1.25.0

Go version

go version go1.25rc1 linux/arm64

Output of `go env` in your module/workspace:

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=''
GOARCH='arm64'
GOARM64='v8.0'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/root/.cache/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/root/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build3464693305=/tmp/go-build -gno-record-gcc-switches'
GOHOSTARCH='arm64'
GOHOSTOS='linux'
GOINSECURE=''
GOMOD='/dev/null'
GOMODCACHE='/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTELEMETRY='local'
GOTELEMETRYDIR='/root/.config/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='local'
GOTOOLDIR='/usr/local/go/pkg/tool/linux_arm64'
GOVCS=''
GOVERSION='go1.25rc1'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

While testing our code with go1.25rc1; moby/moby#50313 (comment), gotestsum failed to compile with an errorr in golang.org/x/tools v0.19.0

Note that golang.org/x/tools v0.19.0 is a pretty old version, but it probably should not be expected for code to fail.

What did you see happen?

docker run --rm golang:1.25rc1 sh -c 'go install gotest.tools/gotestsum@v1.12.0'
go: downloading gotest.tools/gotestsum v1.12.0
go: downloading github.com/dnephin/pflag v1.0.7
go: downloading github.com/fatih/color v1.16.0
go: downloading github.com/google/shlex v0.0.0-20191202100458-e7afc7fbc510
go: downloading golang.org/x/tools v0.19.0
go: downloading github.com/fsnotify/fsnotify v1.7.0
go: downloading golang.org/x/sys v0.18.0
go: downloading github.com/bitfield/gotestdox v0.2.2
go: downloading golang.org/x/sync v0.6.0
go: downloading golang.org/x/term v0.18.0
go: downloading github.com/mattn/go-colorable v0.1.13
go: downloading github.com/mattn/go-isatty v0.0.20
go: downloading golang.org/x/text v0.14.0
go: downloading golang.org/x/mod v0.16.0
# golang.org/x/tools/internal/tokeninternal
pkg/mod/golang.org/x/tools@v0.19.0/internal/tokeninternal/tokeninternal.go:64:9: invalid array length -delta * delta (constant -256 of type int64)

Looks to be here;
https://github.com/golang/tools/blob/v0.19.0/internal/tokeninternal/tokeninternal.go#L62-L64

// If the size of token.FileSet changes, this will fail to compile.
const delta = int64(unsafe.Sizeof(tokenFileSet{})) - int64(unsafe.Sizeof(token.FileSet{}))
var _ [-delta * delta]int

What did you expect to see?

No failures

Isn't this due to the exact situation described in the comment? The structure of token.FileSet changed in 1.25rc1, and thus the compile-time failure is intentional.

x/tools generally needs to be new enough to support newer versions of go.

@thaJeztah

btw, @thaJeztah there is a simpler trick to do the assertion.

var _ = "a"[unsafe.Sizeof(tokenFileSet{}) - unsafe.Sizeof(token.FileSet{})]

[edit] Aha, that is in the tool project instead of moby. :D

Update all dependencies

This also happened in win11 go1.25.0 while I was downloading fyne

Yup, we see this in our CI too. We have slightly older golang.org/x deps because we are trying to maintain 1.19 as a minimum required Go version…

This is our mistake, sorry. A bit of background:

x/tools used unsafe to work around some major performance problems with the token.FileSet datastructure. This fix has since been upstreamed in go/token: add (*FileSet).AddExistingFiles method to add files out of order #73205, so that we no longer need to use unsafe.
The tokeninternal package, which contained this unsafe workaround intended only for gopls, had another use in x/tools at v0.19.0. An unrelated function in the package (not the one that uses unsafe) was used by the gcimporter package, which is reachable through the public API of x/tools. This unintended edge was also subsequently removed, but not before some projects depended on affected versions.

So this was a latent bug in x/tools, which has since been fixed, but is now being encountered in projects depending on the affected versions. Apologies for the breakage.

Would there be any appetite to backport a patch of this to an older version of /x/tools?

In recent releases the minimum go source directive has been bumped by /x/tools.

As noted by Andy above, there are some of us who are trying to keep tooling still working on lower Go versions (for instance, in oapi-codegen we're trying to stick with 1.22

If we upgrade /x/tools to fix some folks' builds on Go 1.25, we're forcing everyone to need to build with Go 1.24

If we could backport this fix, that'd allow us to choose an older tag with maybe Go 1.22 (or 1.23) compatibility to reduce the chain of events forcing everyone else to upgrade too

@jamietanna

Thanks @jamietanna a solid plan.

For context the Fyne library wants to always work with the versions current in the popular package managers. Not everyone manages Go using Go or direct downloads and if their system is completely up to date then ideally their apps should continue to compile without needing toolchain upgrades.

From my digging it seems to be the case that:

If your golang.org/x/tools dependency is more than 2 months old your code will fail to compile with Go 1.25!!!

I use go 1.24 as an alternative and the then latest x/tools package runs well .

@andydotxyz

@andydotxyz yesterday when I use go 1.25.0 with the latest version ,I still got a return"invalid array length -delta * delta (constant -256 of type int64)" .Pay attention ,I also check the version personally .

Please print the whole error. That code is not present in the latest version so something went wrong at your end. Or it's ANOTHER dependency that has the same problem.

@andydotxyz

Reopening because this is a bad, unintentional breakage, and we should reconsider possible mitigations.

To summarize: an optimization to the token.FileSet struct in 1.25 breaks older versions of the x/tools/internal/tokeninternal package that used unsafe to work around certain related performance problems detailed in #73205. In my initial analysis above (#74462 (comment)), I was unfortunately mistaken: the GetLines function is used indirectly by x/tools/go/gcexportdata.Write, and also contains this unsafe trick.

This shouldn't have happened: x/tools should not depend on the internal layout of the token.FileSet struct, and while we need to analyze the impact of this bug, it seems quite bad: as @andydotxyz analyzed, this problem is present in versions of x/tools as recent as 2mo old. Fortunately, among packages in x/tools, go/gcexportdata is infrequently used.

We should investigate potential mitigations. It's gnarly, but here are some potential paths forward:

Revert https://go.dev/cl/675736 for go 1.25.1.
Patch older versions of x/tools (suggested by @jamietanna above). This may be combinatorially complex (there may be many affected versions), and could lead to painful interactions with MVS, but might still be a safe path forward if we retract all the bad versions.
Simply pad the go/token.FileSet struct to be the same size in 1.25 as it was in 1.24, and turn a compile-time error into a (likely unreachable) runtime error. This would have been more viable if not for the reachability of tokeninternal.GetLines through the x/tools/go/gcexportdata API.

feat: Add OnlineStore for MongoDB (feast-dev#6025)

chore(release): release 0.61.0

feat: Add OnlineStore for MongoDB (feast-dev#6025)

chore(release): release 0.61.0

bump golang.org/x/tools@v0.26.0

ci: drop deprecated golint

Don't test on 1.25 due to golang/go#74462

fix: migrate goreleaser from v1 to v2 to fix Go 1.25+ build failure

fix(backends): bump STATICCHECK_VERSION 2024.1.1→2026.1, ERRCHECK_VER…

fix: resolve CI failures - controller timeout, Go 1.25 compat, E2E re…

fix: migrate goreleaser from v1 to v2 to fix Go 1.25+ build failure

Navigation Menu

Repository navigation

x/tools: v0.8.0 through v0.25.0 (Oct 2024) contain public packages that fail to build with Go 1.25.0 #74462

Go version

Output of `go env` in your module/workspace:

What did you do?

What did you see happen?

What did you expect to see?

113 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

x/tools: v0.8.0 through v0.25.0 (Oct 2024) contain public packages that fail to build with Go 1.25.0 #74462

Description

Go version

Output of go env in your module/workspace:

What did you do?

What did you see happen?

What did you expect to see?

Activity

rittneje commented on Jul 3, 2025

seankhliao commented on Jul 3, 2025

zigo101 commented on Jul 3, 2025

Lin-Ziyue commented on Aug 15, 2025

andydotxyz commented on Aug 15, 2025

findleyr commented on Aug 15, 2025

jamietanna commented on Aug 16, 2025

andydotxyz commented on Aug 16, 2025

andydotxyz commented on Aug 16, 2025

Lin-Ziyue commented on Aug 16, 2025

Lin-Ziyue commented on Aug 16, 2025

andydotxyz commented on Aug 16, 2025

findleyr commented on Aug 17, 2025

113 remaining items

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Output of `go env` in your module/workspace: