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)

What happens if you pass the -source flag to vet?

@rasky, could you help me understand why this worked in go1.9 and doesn't in go1.10? Was it a bug that it worked in go1.9?

@bcmills, I get the same error:

-> % go vet -source ./file2.go
# command-line-arguments
./file2.go:4:2: undefined: f

I believe this is related to #21287 and #16086.

For your workflow, could you vet the whole package and filter the output to remove warnings for the generated package?

Moreover, vet is intended to have few or no false-positives. What kinds of warnings are you trying to ignore in the generated code?

For your workflow, could you vet the whole package and filter the output to remove warnings for the generated package?

I could filter output, yes. I just worry about the fragility of that approach, though; is cmd/vet's text output format considered an API which is protected by compatibility guarantees?

For example, in the output here:

-> % go vet -source ./file2.go
# command-line-arguments
./file2.go:4:2: undefined: f

I suppose what I would do is iterate over every line of output. Discard ones that start with a #. For others, resolve the relative path if one appears at the start of the line (which is always relative to cwd, even if absolute file paths were passed in). If the relative path points to a file I know is generated, discard the line. If no lines remain, exit with code 0, else exit with code 1 and print the lines.

This would work today, but I think it could easily break in the future, unless vet's output is part of the compatibility guarantees.

Moreover, vet is intended to have few or no false-positives. What kinds of warnings are you trying to ignore in the generated code?

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.

I think step 1 is to determine whether vet on an incomplete part of a package is actually supported, or just happened to work by accident prior to 1.10. (I don't actually know the answer to that.)

I want to vet the hand-written code, but I don't care about vet issues in the generated 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.

could you help me understand why this worked in go1.9 and doesn't in go1.10? Was it a bug that it worked in go1.9?

Yes, it was a (design) bug. Vet wasn't sophisticated enough to insist, and now it is.