Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/vet: vet fails when listing files unless all files in the package are listed #24668
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
This is how all go tools work (including “go build” for instance). You either don’t give arguments (= current directory), specify a relative path pointing to a package, or specify a list of files that most form a full package.
go vet is now much more precise because it has access to full type information, but it requires to see and vet a whole package.
In your case, assuming you don’t want to fix issues in the generated file, I’d just filter out those files from vet’s output (eg: with grep)
I could filter output, yes. I just worry about the fragility of that approach, though; is
For example, in the output here:
I suppose what I would do is iterate over every line of output. Discard ones that start with a
This would work today, but I think it could easily break in the future, unless vet's output is part of the compatibility guarantees.
Unkeyed composite literals have shown up in github.com/golang/protobuf/protoc-gen-go's output. See golang/protobuf#214. I see now that this has been fixed three weeks ago, though, in golang/protobuf#560, so maybe it's no longer an issue. Maybe I should regenerate and vet all code now.
The reason I want to skip generated files isn't that vet is incorrectly flagging code, though. It's really that I rarely have the ability to fix the problem myself, because the code generator is typically written by someone else. They have to agree that making their generated output pass vet is worthwhile (which isn't always easy!) and then make changes, and then I need to regenerate code.
This is just not supported. Vet works on whole packages. As it gets more sophisticated that's going to become more important. I would suggest grepping away things in generated code, or else writing the generated code in a way that doesn't produce vet errors. The latter (adjusting the generated code) should always be possible. If not, then please open a different issue (and link to it here) for the specific vet error that you can't avoid.
Yes, it was a (design) bug. Vet wasn't sophisticated enough to insist, and now it is.