go vet panics with "inconsistent import: var time.UTC *time.Location previously imported as: var UTC *time.Location"

[patrickdappollonio]

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

$ go version
go version go1.7rc6 linux/amd64

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

$ go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/patrick/Golang"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build590365896=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"

1. What did you do?
   If possible, provide a recipe for reproducing the error.
   A complete runnable program is good.
   A link on play.golang.org is best.

Went to a project in my $GOPATH with dependencies vendored in a vendor/ folder and did...

$ go vet $(go list ./... | grep -v /vendor)

1. What did you expect to see?

Nothing, unless the vet tool found something weird in the code.

1. What did you see instead?

$ go vet $(go list ./... | grep -v /vendor)
panic: inconsistent import:
    var time.UTC *time.Location
previously imported as:
    var UTC *time.Location
 [recovered]
    panic: inconsistent import:
    var time.UTC *time.Location
previously imported as:
    var UTC *time.Location


goroutine 1 [running]:
panic(0x674b20, 0xc4201cbf10)
    /usr/local/go/src/runtime/panic.go:500 +0x1a1
go/types.(*Checker).handleBailout(0xc4200c21c0, 0xc4200d58e8)
    /usr/local/go/src/go/types/check.go:213 +0xae
panic(0x674b20, 0xc4201cbf10)
    /usr/local/go/src/runtime/panic.go:458 +0x243
go/internal/gcimporter.(*importer).declare(0xc42025edd0, 0x7f64a0, 0xc4202eb770)
    /usr/local/go/src/go/internal/gcimporter/bimport.go:175 +0x17c
go/internal/gcimporter.(*importer).obj(0xc42025edd0, 0xfffffffffffffffc)
    /usr/local/go/src/go/internal/gcimporter/bimport.go:195 +0x1b4
go/internal/gcimporter.BImportData(0xc4200132f0, 0xc4202a0000, 0x39d43, 0x3fe00, 0xc42000f941, 0x4, 0x0, 0x4, 0xc41fff1298, 0x0)
    /usr/local/go/src/go/internal/gcimporter/bimport.go:88 +0x390
go/internal/gcimporter.Import(0xc4200132f0, 0xc42000f941, 0x4, 0x7fffd09adced, 0xa, 0xc420170b90, 0x0, 0x0)
    /usr/local/go/src/go/internal/gcimporter/gcimporter.go:166 +0x551
go/importer.gcimports.ImportFrom(0xc4200132f0, 0xc42000f941, 0x4, 0x7fffd09adced, 0xa, 0x0, 0x2, 0x4, 0x0)
    /usr/local/go/src/go/importer/importer.go:70 +0x67
go/types.(*Checker).collectObjects(0xc4200c21c0)
    /usr/local/go/src/go/types/resolver.go:191 +0x826
go/types.(*Checker).checkFiles(0xc4200c21c0, 0xc4200362d8, 0x1, 0x1, 0x0, 0x0)
    /usr/local/go/src/go/types/check.go:225 +0xaa
go/types.(*Checker).Files(0xc4200c21c0, 0xc4200362d8, 0x1, 0x1, 0xc42015b170, 0xc4200d5960)
    /usr/local/go/src/go/types/check.go:218 +0x49
go/types.(*Config).Check(0xc42016a900, 0xc42000f8e0, 0xa, 0xc420011740, 0xc4200362d8, 0x1, 0x1, 0xc4201703c0, 0x100, 0xc4200001a0, ...)
    /usr/local/go/src/go/types/api.go:344 +0x1a3
main.(*Package).check(0xc4200767e0, 0xc420011740, 0xc4200362d8, 0x1, 0x1, 0xc4200362e0, 0x0)
    /usr/local/go/src/cmd/vet/types.go:76 +0x370
main.doPackage(0x6cf324, 0x1, 0xc42000a630, 0x1, 0x1, 0x0, 0x1)
    /usr/local/go/src/cmd/vet/main.go:336 +0x999
main.main()
    /usr/local/go/src/cmd/vet/main.go:244 +0x345
exit status 2

[ALTree]

Dup of #16112 and several others. Caused by out-of-date .o files, go install will fix it.

[patrickdappollonio]

Thanks @ALTree! I'll close it.

[glasser]

It seems weird to me that this issue has been closed in all of its dups. While there is a workaround, it's still a pretty bad user experience. (My coworker ran into it today as soon as he experimented with upgrading our project to 1.7.)

Is the thought that everybody who has the old .o files is likely to discover the workaround before a 1.7.1 would be released anyway, and that future versions won't have this problem because the exporter format change won't happen again?

[bradfitz]

Yeah, this is pretty sad.

@alandonovan, @griesemer, any thoughts?

[griesemer]

Export format changes will still happen, but hopefully they will be handled more smoothly. There is support for an internal version string. There's also an open issue regarding this, assigned to me (#16244).

That said, this particular situation is due to a buggy export format that made its way into various libraries which didn't get recompiled after the fix - this would have been very hard to prevent no matter what. We don't really make any guarantees that object files (and thus the embedded export data) are compatible across different compiler versions, and certainly not if built with unreleased compilers built at tip.

But going forward, the compiler will complain with a more specific error message if outdated export data is found (i.e., with the fix of #16244).

[glasser]

Now that you mention it, I think my coworker who ran into this issue had experimented with some of the 1.7 RCs.