hit the same this morning, had to downgrade go install golang.org/x/tools/gopls@v0.13.2

suspecting https://go-review.googlesource.com/c/tools/+/537118 👀

        // If type size information is needed but unavailable.
	// reject the whole Load since the error is the same for every package.
	ld.sizes = types.SizesFor(response.Compiler, response.Arch)
	if ld.sizes == nil && ld.Config.Mode&(NeedTypes|NeedTypesSizes|NeedTypesInfo) != 0 {
		return nil, fmt.Errorf("can't determine type sizes for compiler %q on GOARCH %q",
			response.Compiler, response.Arch)
	}

Hi, thanks very much for the report, and you are correct that this is related to https://go-review.googlesource.com/c/tools/+/537118. However, that CL was meant to turn a panic into an error -- if downgrading fixed the problem, there's still something we don't understand.

Can you please share the version of Go used to compile gopls (which can be obtained via gopls -v version), as well as the precise Go version (go version). Are you by any chance using go1.21.3?

CC @adonovan

More questions:

Can you please report the output of the following query, run from your workspace directory?

go list -f "{{context.GOARCH}} {{context.Compiler}}" -- unsafe

Does restarting gopls@v0.14.0 fix the problem? Can you try this a few times?

One more: do you by any chance have GOPACKAGESDRIVER set?

Version used to compile gopls: go: go1.19.5

go version: go version go1.19.5 darwin/amd64

❯ go list -f "{{context.GOARCH}} {{context.Compiler}}" -- unsafe
amd64 gc

No amount of restarting seems to be doing the trick

Yes, my GOPACKAGESDRIVER is set through this command: exec bazel run -- @io_bazel_rules_go//go/tools/gopackagesdriver "${@}"

Note: I'm using Bazel and VSCode, all the go commands I ran from .dist/mypkg/external/go_sdk/bin/go

Awesome, thank you for following up. In that case, I think we understand this and will cut a patched prerelease soon. In short: the Arch and Compiler field were added to the driver response, and go/packages was not tolerant of missing fields.

It looks like the bazel driver was updated to set the missing fields in bazelbuild/rules_go@6e10f8c, so you may also be able to fix this by updating bazel.

For other folks paying attention to this issue: can anyone else please confirm that they have a GOPACKAGESDRIVER set? We believe that is the only way to hit this bug.

This should be fixed in v0.14.1-pre.1:

go install golang.org/x/tools/gopls@v0.14.1-pre.1

Could anyone here please try that out to confirm? With your confirmation, we will release v0.14.1 tomorrow.

Since it's Friday and I have yet to hear confirmation of the fix, let's defer the release until Monday.

go install golang.org/x/tools/gopls@v0.14.1-pre.1

This worked for me, thank you!

@Urvik08 thanks for confirming!

@findleyr v0.14.1-pre.1 also fixed the problem for me, and fyi yes I'm also using GOPACKAGESDRIVER=exec bazel run -- @io_bazel_rules_go//go/tools/gopackagesdriver "${@}"

Thank you for the fix! Have a great weekend.

go install golang.org/x/tools/gopls@v0.14.1-pre.1

This works for me too. I'm also using Bazel and go version go1.21.3 linux/amd64. Thanks for the quick fix!

This works for me too. I'm also using Bazel. Thanks for the quick fix!

Thanks all. This is released as gopls@v0.14.1:

go install golang.org/x/tools/gopls@v0.14.1