Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

staticcheck: Fails with Go 1.24: internal error in importing ... (unsupported version: 2) #1627

Open
stefanb opened this issue Jan 18, 2025 · 5 comments
Labels

Comments

@stefanb
Copy link

stefanb commented Jan 18, 2025

While testing Go 1.24 (rc1 and rc2) in

I noticed staticcheck is failing with a simple test from homebrew formula staticcheck.rb, reproduced below:

$ go1.24rc2 version
go version go1.24rc2 darwin/arm64

$ go1.24rc2 run honnef.co/go/tools/cmd/staticcheck@latest .
-: internal error in importing "internal/byteorder" (unsupported version: 2); please report an issue (compile)
-: internal error in importing "internal/cpu" (unsupported version: 2); please report an issue (compile)
-: internal error in importing "internal/goarch" (unsupported version: 2); please report an issue (compile)
-: internal error in importing "internal/goos" (unsupported version: 2); please report an issue (compile)
-: internal error in importing "math/bits" (unsupported version: 2); please report an issue (compile)
exit status 1

$ go1.24rc2 run honnef.co/go/tools/cmd/staticcheck@latest -debug.version
staticcheck 2024.1.1 (0.5.1)

Compiled with Go version: go1.24rc2
Main module:
        honnef.co/go/[email protected] (sum: h1:4bH5o3b5ZULQ4UrBmP+63W9r7qIkqJClEA9ko5YKx+I=)
Dependencies:
        github.com/BurntSushi/[email protected] (sum: h1:pxW6RcqyfI9/kWtOwnv/G+AzdKuy2ZrqINhenH4HyNs=)
        golang.org/x/exp/[email protected] (sum: h1:1P7xPZEwZMoBoz0Yze5Nx2/4pxj6nw9ZqHWXqP0iRgQ=)
        golang.org/x/[email protected] (sum: h1:zY54UmvipHiNd+pm+m0x9KhZ9hl1/7QNMyxXbc6ICqA=)
        golang.org/x/[email protected] (sum: h1:YsImfSBoP9QPYL0xyKJPq0gcaJdG3rInoqxTWbfQu9M=)
        golang.org/x/[email protected] (sum: h1:SHq4Rl+B7WvyM4XODon1LXtP7gcG49+7Jubt1gWWswY=)

Same test with go 1.23 works fine:

$ go version
go version go1.23.5 darwin/arm64

$ go run honnef.co/go/tools/cmd/staticcheck@latest .
main.go:6:2: should merge variable declaration with assignment on next line (S1021)
exit status 1

$ go run honnef.co/go/tools/cmd/staticcheck@latest -debug.version
staticcheck 2024.1.1 (0.5.1)

Compiled with Go version: go1.23.5
Main module:
        honnef.co/go/[email protected] (sum: h1:4bH5o3b5ZULQ4UrBmP+63W9r7qIkqJClEA9ko5YKx+I=)
Dependencies:
        github.com/BurntSushi/[email protected] (sum: h1:pxW6RcqyfI9/kWtOwnv/G+AzdKuy2ZrqINhenH4HyNs=)
        golang.org/x/exp/[email protected] (sum: h1:1P7xPZEwZMoBoz0Yze5Nx2/4pxj6nw9ZqHWXqP0iRgQ=)
        golang.org/x/[email protected] (sum: h1:zY54UmvipHiNd+pm+m0x9KhZ9hl1/7QNMyxXbc6ICqA=)
        golang.org/x/[email protected] (sum: h1:YsImfSBoP9QPYL0xyKJPq0gcaJdG3rInoqxTWbfQu9M=)
        golang.org/x/[email protected] (sum: h1:SHq4Rl+B7WvyM4XODon1LXtP7gcG49+7Jubt1gWWswY=)
@stefanb stefanb added bug needs-triage Newly filed issue that needs triage labels Jan 18, 2025
@stefanb stefanb changed the title Fails with Go 1.24: internal error in importing ... (unsupported version: 2) staticcheck: Fails with Go 1.24: internal error in importing ... (unsupported version: 2) Jan 18, 2025
@stefanb
Copy link
Author

stefanb commented Jan 18, 2025

It seems that it was already fixed on master in v0.5.1...master

$ go1.24rc2 run honnef.co/go/tools/cmd/staticcheck@master .
main.go:6:2: should merge variable declaration with assignment on next line (S1021)
exit status 1

$ go1.24rc2 run honnef.co/go/tools/cmd/staticcheck@master -debug.version
staticcheck (devel, v0.6.0-0.dev.0.20250112185414-21df14b396f6)

Compiled with Go version: go1.24rc2
Main module:
        honnef.co/go/[email protected] (sum: h1:V0zVc5mjXZdaUSO26gkYCmjBSju5zKVkHY0O7K4TxLg=)
Dependencies:
        github.com/BurntSushi/[email protected] (sum: h1:pxW6RcqyfI9/kWtOwnv/G+AzdKuy2ZrqINhenH4HyNs=)
        golang.org/x/exp/[email protected] (sum: h1:1P7xPZEwZMoBoz0Yze5Nx2/4pxj6nw9ZqHWXqP0iRgQ=)
        golang.org/x/[email protected] (sum: h1:vvrHzRwRfVKSiLrG+d4FMl/Qi4ukBCE6kZlTUkDYRT0=)
        golang.org/x/[email protected] (sum: h1:3NFvSEYkUoMifnESzZl15y791HH1qU2xm6eCJU5ZPXQ=)
        golang.org/x/[email protected] (sum: h1:oFU9pkj/iJgs+0DT+VMHrx+oBKs/LJMV+Uvg78sl+fE=)

So it likely just needs a new release.

@dominikh
Copy link
Owner

The next release of Staticcheck will coincide with the Go 1.24 release.

@dominikh dominikh removed the needs-triage Newly filed issue that needs triage label Jan 18, 2025
@timothy-king
Copy link
Contributor

timothy-king commented Jan 18, 2025

-: internal error in importing "internal/byteorder" (unsupported version: 2); please report an issue (compile) means the export data when generated with GOEXPERIMENT=aliastypeparams. This is on by default for 1.24 (and off for <=1.23).

[Edit: none of the following makes sense for the error message. Apologies.] I very strongly suspect this is golang/go#69772. staticcheck's go.mod is 1.22. So to handle 1.24 code with a 1.24 toolchain and a 1.22 language version, one needs to explicitly set GODEBUG gotypesalias=1 (but only do this when the toolchain is >=1.23 [because 1.22 toolchain support is just not good enough]) or bump the go.mod to >= 1.23 to bump the language version. Example fixes in https://go.dev/cl/619395. This adds this slightly cryptic file to each package main:

//go:build go1.23

//go:debug gotypesalias=1

package main

This is all awful tech debt caused by needing go/types to be backwards compatible with non-materialized aliases.

@dominikh
Copy link
Owner

As this works on master but not with the latest release of Staticcheck, I believe this is actually caused by using an old version of golang.org/x/tools/go/gcexportdata.

@timothy-king
Copy link
Contributor

As this works on master but not with the latest release of Staticcheck, I believe this is actually caused by using an old version of golang.org/x/tools/go/gcexportdata.

Yes. This makes more sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants