cmd/go, cmd/vet: make vet work with gccgo
commit70d336ec8b4bc5b56c3404e6f5acab48690e43d4
authorian <ian@138bc75d-0d04-0410-961f-82ee72b054a4>
Wed, 30 May 2018 00:16:58 +0000 (30 00:16 +0000)
committerian <ian@138bc75d-0d04-0410-961f-82ee72b054a4>
Wed, 30 May 2018 00:16:58 +0000 (30 00:16 +0000)
treef26362247107542c54e9b998b7c9003de6914215
parent09a0f9a7f0f34969b974b7f9aa6c4602495086f2
cmd/go, cmd/vet: make vet work with gccgo

    Backport https://golang.org/cl/113715 and https://golang.org/cl/113716:

    cmd/go: don't pass -compiler flag to vet

    Without this running go vet -compiler=gccgo causes vet to fail.
    The vet tool does need to know the compiler, but it is passed in
    vetConfig.Compiler.

    cmd/go, cmd/vet, go/internal/gccgoimport: make vet work with gccgo

    When using gccgo/GoLLVM, there is no package file for a standard
    library package. Since it is impossible for the go tool to rebuild the
    package, and since the package file exists only in the form of a .gox
    file, this seems like the best choice. Unfortunately it was confusing
    vet, which wanted to see a real file. This caused vet to report errors
    about missing package files for standard library packages. The
    gccgoimporter knows how to correctly handle this case. Fix this by

    1) telling vet which packages are standard;
    2) letting vet skip those packages;
    3) letting the gccgoimporter handle this case.

    As a separate required fix, gccgo/GoLLVM has no runtime/cgo package,
    so don't try to depend on it (as it happens, this fixes golang/go#25324).

    The result is that the cmd/go vet tests pass when using -compiler=gccgo.

    Reviewed-on: https://go-review.googlesource.com/114516

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@260913 138bc75d-0d04-0410-961f-82ee72b054a4
gcc/go/gofrontend/MERGE
libgo/go/cmd/go/internal/load/pkg.go
libgo/go/cmd/go/internal/vet/vetflag.go
libgo/go/cmd/go/internal/work/exec.go
libgo/go/cmd/vet/main.go
libgo/go/go/internal/gccgoimporter/importer.go