cmd/vet: "go tool vet" gives error "invalid command: want .cfg file"

[ugorji]

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

$ go version
go version devel +e003c6f971 Mon Nov 19 17:33:37 2018 +0000 darwin/amd64

Does this issue reproduce with the latest release?

I see this issue on tip

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

go env Output

$ go env
GOARCH="amd64"
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"

What did you do?

go tool vet -loopclosure *.go

What did you expect to see?

I expected go tool vet to run successfully.

What did you see instead?

vet: invalid command: want .cfg file (this reduced version of vet is intended to be run only by the 'go vet' command)

I found out about this error because I kept getting it in my emacs messages during development.

The error I got came from flycheck (a well known syntax checker for emacs supporting many many languages and modes). On further investigation into the sub-module of flycheck, I saw that they were executing "go tool vet" and showing me this error on each save.

Suspicious state from syntax checker go-vet: Flycheck checker go-vet returned non-zero exit code 1, but its output contained no errors: vet: invalid command: want .cfg file (this reduced version of vet is intended to be run only by the 'go vet' command)

Try installing a more recent version of go-vet, and please open a bug report if the issue persists in the latest release.  Thanks!

[bcmills]

@alandonovan has been refactoring cmd/vet.

[Prativa20]

I am getting this error as well.

vet: invalid command: want .cfg file (this reduced version of vet is intended to be run only by the 'go vet' command)
make: *** [check] Error 1
The command "make check race release" exited with 2.

go version devel +339e5ff189 Tue Nov 20 20:56:13 2018 +0000 linux/amd64

[ysmolsky]

This has broken the workflow under emacs's flycheck calling go vet.

[ianlancetaylor]

@alandonovan @matloob Can you give some background on this? The basic issue is that go tool vet no longer works. But we have documented that as working in the past. Is there any alternative?

[alandonovan]

Apologies for the slow response--I was hoping to come up with a bright idea, but have had none. My impression throughout the vet redesign, based on discussions with Russ, was that 'go tool vet' was not something we intended to support; furthermore vet analyzers have been increasingly reliant on the well-typedness of their inputs, so the old vet could crash if run directly. But as always, reality is more complicated: supported or not, people were using it, and it was a lot faster than 'go vet', making it attractive for uses such as flycheck, and cmd/vet/all.

The choices are:

• make Flycheck either use go vet, or not run vet at all. This is unsatisfying for those who use vet through Flycheck.
• build an alternative analysis driver that works on incomplete packages with missing dependencies. Most Analyzers using the new API do not set RunDespiteErrors, so the new driver should not run them. One could audit those Analyzers, make them robust, and enable RunDespiteErrors, but it's a lot of tricky work; or one could just pretend RunDespiteErrors is true, which is in effect what the old vet did, and deal with crashes and false positives as they occur. This is unsatisfying to users and maintainers of the analysis tools.
• exhume the old cmd/vet and throw away the new analysis API. This is unsatisfying to users and maintainers of the analysis tools.

None of the options are good, but I know which one I prefer.

I'm sorry I didn't anticipate this problem.

[ysmolsky]

I am somewhat confused. @alandonovan, I know that you have refactored go vet. Where can I read about this from the user's point of view? I could not find any documentation explain what happened in details. Where can I learn the difference between go vet and go vet tool? I want to help this issue because I relay on FlyCheck as my daily tool and cannot live without it.

[ianlancetaylor]

@ysmolsky At the moment on tip go vet works much as it did before, only better, and go tool vet doesn't work at all. If this is what gets released in 1.12, it will of course be documented in the release notes.

Is it possible for FlyCheck to use go vet rather than go tool vet?

[ysmolsky]

@ianlancetaylor I have created a ticket flycheck/flycheck#1523. It is possible to use go vet but we lose some functionality that way.

[alandonovan]

@ysmolsky You have probably seen this doc https://docs.google.com/document/d/1-azPLXaLgTCKeKDNg0HVMq2ovMlD-e7n1ZHzZVzOlJk which describes the changes from the point of view of analysis tool writers. I have not written a doc from the vet user's point of view because I did not anticipate that there would be any significant changes, although of course I underestimated the significance of removing support for directly executing 'go tool vet'.

[ysmolsky]

@alandonovan thank you for the link. I have found temporary solution by switching flycheck to go vet. One thing bothers me: go vet reports syntax errors and stops there. To fix that we would need to pick 2nd options you explained above (about alternative analysis driver that run analyzers with RunDespiteErrors set to true). Is this correct?

[alandonovan]

@ysmolsky cmd/vet should still run those analyzers that identify themselves as robust in the face of syntax or type errors, but they are a minority. Perhaps more of them could be made robust with fairly marginal effort. It wouldn't require a new analysis driver.

[gopherbot]

Change https://golang.org/cl/152217 mentions this issue: go/analysis/unitchecker: improve error message for go tool vet

[gopherbot]

Change https://golang.org/cl/152257 mentions this issue: cmd/vendor/golang.org/x/tools/go/analysis: update

[ianlancetaylor]

The error message now says

invoking "go tool vet" directly is unsupported; use "go vet"

Our current plan is to declare that go tool vet is no longer supported.

[gopherbot]

Change https://golang.org/cl/152161 mentions this issue: doc: release notes: "go tool vet" is no longer supported

[ysmolsky]

@ianlancetaylor, sounds like a plan. If that is decided, this ticket can be closed as no more work is anticipated here. Other tools ought to be fixed.

[ianlancetaylor]

As far as I know everything in the Go project is fixed and there is nothing to do here. We may need to revisit this based on reaction to the beta, but closing for now.