cmd/vet: go vet failing on directory with no non-test files

[campoy]

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

go version devel +23aefcd9ae Wed Jan 10 00:00:40 2018 +0000 darwin/amd64

Does this issue reproduce with the latest release?

yes

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

GOARCH="amd64" GOBIN="" GOCACHE="/Users/francesc/Library/Caches/go-build" GOEXE="" GOHOSTARCH="amd64" GOHOSTOS="darwin" GOOS="darwin" GOPATH="/Users/francesc" GORACE="" GOROOT="/Users/francesc/go" GOTMPDIR="" GOTOOLDIR="/Users/francesc/go/pkg/tool/darwin_amd64" GCCGO="gccgo" CC="clang" CXX="clang++" CGO_ENABLED="1" 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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/tm/816df9c9399_1fnz90k6gfq80000gn/T/go-build262771710=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

As part of my continuous build steps I run go vet on all my code.
In order to do this I used to run go list ./... | grep -v vendor | xargs go vet.

Until go1.9 this was working correctly but as you can see here it stopped working with go1.10.

What did you expect to see?

Running go vet in a directory with only the the test below should give a go vet warning.

package main_test

import (
	"fmt"
	"testing"
)

func TestSomething(t *testing.T) {
	fmt.Printf("Something missing %s")
}

$ go vet
main_test.go:9: missing argument for Printf("%s"): format reads arg 1, have only 0 args
exit status 1

What did you see instead?

The output is not a warning, but an error to load the package.

$ go vet
go build github.com/campoy/test/foo: no non-test Go files in .../foo

[mvdan]

The best part is that it does run properly via go test:

$ go test
# mvdan.cc/p
./f_test.go:9: Printf format %s reads arg #1, but call has only 0 args
FAIL    mvdan.cc/p [build failed]

Looking into this, as I looked into another package loading bug recently.

[0xmohit]

This bisects to 561786.

[mvdan]

@0xfaded yes - that is the line that swapped load.Packages for load.PackagesForBuild. The subtle distinction here is that we don't require the package to be buildable, just loadable with type information. I am looking at what the best fix would be.

Edit: info above may be wrong, was too quick to jump to conclusions.

[mvdan]

This issue is trickier than I thought, as it involves the fairly new cmd/go/internal/work. When the "vet" action is sent to it, it adds a dependency on a "build" action. This action then fails if there are no non-test Go files:

// Sanity check only, since Package.load already checked as well.
if len(gofiles) == 0 {
        return &load.NoGoError{Package: a.Package}
}

I have tried multiple ways of skipping this error or this build step, but it just ends up with the vet step either erroring or doing nothing useful.

There must be something that go test is doing to get the vet tool to work properly, but I haven't yet figured out what. I tried moving p.TestGoFiles to p.GoFiles similar to what it does in builderTest, but that just resulted in various dependency loading errors.

I'm going to let @rsc have a look, as he wrote all this code and will likely find the correct fix in no time.

[gopherbot]

Change https://golang.org/cl/87636 mentions this issue: cmd/go: apply "go vet" to test files