x/tools/go/analysis: divide by zero in atomicalign.check64BitAlignment

[zeebo]

What version of Go are you using (go version)?

$ go version
go version go1.12.1 linux/amd64

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/jeff/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/jeff/go"
GOPROXY=""
GORACE=""
GOROOT="/nix/store/4kvx51wk8sjglkns8bnrragw4hqvssiw-go-1.12.1/share/go"
GOTMPDIR=""
GOTOOLDIR="/nix/store/4kvx51wk8sjglkns8bnrragw4hqvssiw-go-1.12.1/share/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build548840513=/tmp/go-build -gno-record-gcc-switches"

What did you do?

I'm using gopls and I opened a file in a module that contained

package foo

import "sync/atomic"

type T struct {
	f struct {
		y uint64
	}
}

var _ = atomic.LoadUint64(&(&T{}).f.y)

The key part is that it's attempting to access a field inside of an anonymous struct with sync/atomic.

What did you expect to see?

No crash.

What did you see instead?

panic: runtime error: integer divide by zero

goroutine 14 [running]:
go/types.align(...)
	/goroot/src/go/types/sizes.go:256
go/types.(*StdSizes).Offsetsof(0xc00021c370, 0xc0002260e0, 0x1, 0x1, 0x1, 0xc0002260e0, 0x0)
	/goroot/src/go/types/sizes.go:97 +0x144
golang.org/x/tools/go/analysis/passes/atomicalign.check64BitAlignment(0xc0002221b0, 0xc000018e30, 0xa, 0x8fb0c0, 0xc00000ebe0)
	/build/go/src/golang.org/x/tools/go/analysis/passes/atomicalign/atomicalign.go:105 +0x1cd
golang.org/x/tools/go/analysis/passes/atomicalign.run.func1(0x8f50a0, 0xc000030d00)
	/build/go/src/golang.org/x/tools/go/analysis/passes/atomicalign/atomicalign.go:65 +0x16e
golang.org/x/tools/go/ast/inspector.(*Inspector).Preorder(0xc0000ebd60, 0xc00004ed40, 0x1, 0x1, 0xc0001eed30)
	/build/go/src/golang.org/x/tools/go/ast/inspector/inspector.go:77 +0x9f
golang.org/x/tools/go/analysis/passes/atomicalign.run(0xc0002221b0, 0x0, 0x0, 0x0, 0x0)
	/build/go/src/golang.org/x/tools/go/analysis/passes/atomicalign/atomicalign.go:42 +0x155
golang.org/x/tools/internal/lsp/source.(*Action).execOnce(0xc0000e4420, 0xc0000f0dc0)
	/build/go/src/golang.org/x/tools/internal/lsp/source/analysis.go:156 +0x727
golang.org/x/tools/internal/lsp/source.(*Action).exec.func1()
	/build/go/src/golang.org/x/tools/internal/lsp/source/analysis.go:93 +0x33
sync.(*Once).Do(0xc0000e4420, 0xc00004ef88)
	/goroot/src/sync/once.go:44 +0xb3
golang.org/x/tools/internal/lsp/source.(*Action).exec(0xc0000e4420, 0xc0000f0dc0)
	/build/go/src/golang.org/x/tools/internal/lsp/source/analysis.go:92 +0x63
golang.org/x/tools/internal/lsp/source.execAll.func1(0xc0000e4420)
	/build/go/src/golang.org/x/tools/internal/lsp/source/analysis.go:83 +0x3d
created by golang.org/x/tools/internal/lsp/source.execAll
	/build/go/src/golang.org/x/tools/internal/lsp/source/analysis.go:86 +0x5a

[josharian]

@mvdan

[mvdan]

@arl worked on the analyzer, so perhaps he wants to look into this.

[arl]

Ok, you can assign it to me

[mvdan]

@zeebo does it happen with go vet too? If so, we might want to consider a backport to keep vet from crashing on valid programs.

[zeebo]

It doesn’t crash go vet.

[arl]

Indeed it doesn't crash vet so this should probably be reported to gopls.
However, with the latest gopls I wasn't able to reproduce either (fb37f6ba82613749b0b522aa509da78361849fc3 in x/tools), though I've never used gopls before so I might have done something wrong: I created a project with that file and ensured gopls (via VSCode) was providing type info for it, saw nothing in gopls log.

@zeebo could you check if this is still valid please?

[stamblerre]

gopls doesn't work correctly with build tags, so I think that's probably what is happening here. #32413 is likely related.

[arl]

gopls doesn't work correctly with build tags

atomicalign vet analyser does use build tags to make the analyser a no-op on non-affected architectures, so yeah that's probably what is happening.

[zeebo]

I can confirm that it doesn't crash for me anymore.

[arl]

I believe this issue can be close