cmd/vet: reports different results on different computers

[HaraldNordgren]

Please answer these questions before submitting your issue. Thanks!

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

Both people use go version go1.8.3 darwin/amd64.

Does this issue reproduce with the latest release?

Later versions show new/different results, but they are still not consistent across different computers.

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

 % go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/harald/go"
GORACE=""
GOROOT="/usr/local/Cellar/go/1.8.3/libexec"
GOTOOLDIR="/usr/local/Cellar/go/1.8.3/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/9z/mc8cz_m17256_jt014kb6zv00000gn/T/go-build528089650=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"

Only difference on the other machine is GOPATH="/Users/uwe/dev/go".

What did you do?

Initialize a struct with multiple keys. Without explicitly specifying each key, but instead relying on the ordering. This would constitute a linter error with certain linter settings.

What did you expect to see?

Same linter output on each computer, so Composite literal uses unkeyed fields.

What did you see instead?

The linter error appears on the computer with, GOPATH=$HOME/dev/go but not on the one with GOPATH=$HOME/go.

(I don't think necessarily it's related to the GOPATH. Consider it just an identifier for the different computers in this case.)

Related tickets

#12636

[mvdan]

Are you positive it's not a duplicate of the issue above?

Could you provide a way to reproduce the program? A self-contained program or set of packages would be best.

Does this happen with 1.9rc2?

[HaraldNordgren]

The problem seems to be related to differences in how the normal compilation and running on programs handle paths, compared to vet.

Running go install as a pre-step cleared it up. And now the linting works in the same way across machines.

Running vet with verbose (-v) revealed the path problem and gave a non-zero exit code.

Interestingly enough, without verbose, it fails silently with exit code 0.