Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
campoy opened this issue Jan 10, 2018 · 5 comments
Closed

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

campoy opened this issue Jan 10, 2018 · 5 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. release-blocker
Milestone
Go1.10

Comments

@campoy
Copy link
Contributor

campoy commented Jan 10, 2018

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
@campoy campoy mentioned this issue Jan 10, 2018
Closed
@mvdan mvdan self-assigned this Jan 10, 2018
@mvdan mvdan added this to the Go1.10 milestone Jan 10, 2018
@mvdan
Copy link
Member

mvdan commented Jan 10, 2018

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
Copy link
Contributor

0xmohit commented Jan 10, 2018

This bisects to 561786.

@mvdan
Copy link
Member

mvdan commented Jan 10, 2018 •
edited

@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
Copy link
Member

mvdan commented Jan 10, 2018

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.

@mvdan mvdan assigned rsc and unassigned mvdan Jan 10, 2018
@ianlancetaylor ianlancetaylor added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. release-blocker labels Jan 10, 2018
@campoy campoy mentioned this issue Jan 10, 2018
Merged
@gopherbot
Copy link

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

@0xmohit 0xmohit mentioned this issue Jan 16, 2018
Closed
@mvdan mvdan mentioned this issue Jan 24, 2018
Closed
@golang golang locked and limited conversation to collaborators Jan 23, 2019
@rsc rsc removed their assignment Jun 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. release-blocker
Projects
None yet
Milestone
Go1.10
Development

No branches or pull requests
6 participants
@rsc @campoy @ianlancetaylor @mvdan @0xmohit @gopherbot