@rsc which package did you use to import the data into go/types?

I believe that's who's responsible for ensuring that unsafe is always the same.

(Not 100% sure about that but I've been poking around in various importers the last few days and noticed code like "if importing unsafe then return types.Unsafe")

Reproduction:

touch $(go env GOROOT)/pkg/$(go env GOOS)_$(go env GOARCH)/unsafe.a
go test -short go/types

It fails quite loudly. The first few lines of output are:

--- FAIL: TestBuiltinSignatures (0.00s)
	builtins_test.go:141: var s []int; _ = append(s): 1:19: could not import unsafe (/Users/rsc/go/pkg/darwin_amd64/unsafe.a: can't find export data (EOF))
	builtins_test.go:141: var s []int; _ = append(s, 0): 1:19: could not import unsafe (/Users/rsc/go/pkg/darwin_amd64/unsafe.a: can't find export data (EOF))

and so on.

go/types just uses whatever importer is provided. In this case, it's going to be the default importer which is the gc importer. Since the unsafe.a file exists, it tries to import that.

It's certainly easy to not call any importer at all for "unsafe".

Change https://golang.org/cl/67634 mentions this issue: go/types: import "unsafe" always means package unsafe

The Go vendor spec explicitly says that
https://golang.org/s/go15vendor:

These rules...apply to standard library packages. If someone wants to vendor (and therefore hide the standard library version of) “math” or even “unsafe”, they can.

It sounds like a bug in gc or 'go build' to me, not go/types.

ping @rsc

Sigh. Obviously my memory is going. OK. Well, the importer is going to get rewritten as part of package management and workspace abstraction issues, so that will probably fix this anyway. So I guess nothing to do now.

FWIW, it doesn't make a lot of sense to me to vendor package unsafe - I'd be fine to disallow this and perhaps even state it in the spec that importing unsafe means only one thing and cannot be changed.