This is a consequence of AST trimming that gopls does to reduce memory. There are other similar issues (for example #50196).

IIRC AST trimming provides modest but not major benefit to most users (~25% memory reduction). I am not sure that is worth the loss in precision. I would like to remove our AST trimming in favor of teaching gopls to load fewer packages, but have hesitated to simply remove it before we have offsetting optimizations. Maybe we should.

We've found a case in which there is a conflict between fieldalignment the analyser and fieldalignment the tool:

type t struct {
	a *int
	b netip.AddrPort
}

The analyser complains with struct of size 16 could be 8, but the tool sees nothing wrong. On the other hand, if we move a down, the analyser remains silent while the tool correctly notes: struct with 40 pointer bytes could be 32. This is using golang.org/x/tools/gopls@v0.0.0-20220628132954-2a900561e78a and fieldalignment at v0.1.12-0.20220628132954-2a900561e78a as well.

Is there a way to disable the AST trimming optimization? If not, could adding that option or fixing the analyser receive a higher priority from the gopls team? Thanks.

There is no option, but we can add such an option with higher priority.

It will take us longer to disable trimming entirely (we'd like to offset with other optimizations).

Change https://go.dev/cl/415503 mentions this issue: internal/lsp/cache: don't trim unexported struct fields

I've checked out change 415503, built it, cleared the cache, and tried using the new gopls on the example I provided before:

git fetch https://go.googlesource.com/tools refs/changes/03/415503/5 && git checkout -b change-415503 FETCH_HEAD
cd ./gopls/
go install
go clean -cache
nvim ~/tmp/main.go

Yet, the incorrect warning is still there. Is there any other cache I need to remove? I haven't found anything that would seem like it belongs to gopls in ~/.cache, and the troubleshooting guide doesn't mention any separate cache either. gopls version shows (devel).

Am I doing something wrong?

@ainar-g thanks for testing this out.

Unfortunately this CL addresses only half of the problem: the other half is that we don't compute analysis facts for the imported packages: https://go.dev/issue/48738. We are going to work on that soon, as well.

Unfortunately this CL addresses only half of the problem

Indeed, I meant to use "updates" not "fixes" in the CL description to relate it to this issue. Fixed (I mean updated) now.

And thanks @ainar-g for testing it out.

Computing analysis facts is a large project. I have tentatively moved this to v0.10.0, just so it stays among our top priorities, but the likely reality is that it will take us ~months to have proper analysis facts.

Proper analysis facts are one of the major outstanding priorities for gopls.

@adonovan is this fixed now that you've landed your new analysis driver?

Yes, I just verified that the original example now works. I was thinking of adding a test, but it's the exact same mechanism tested by the existing test of facts using the printf driver, so it doesn't seem necessary.

For anyone who finds this issue: be aware that the new analysis driver is a big change to gopls' execution model (we're now doing analysis using an on-disk cache of export data and facts). There will be a temporary performance overhead due to double-type-checking, which we plan to mitigate before the next release. There also may be bugs.