cmd/vet does already flag certain kinds of invalid struct tags. This would extend that to look specifically for invalid json struct tags. And, logically, xml, etc.

One catch here will be tooling outside the Go toolchain that uses these tags. For example, easyjson adds an intern directive to the json tag to enable interning for fields on unmarshal. If go vet disallows this it might have a negative effect, though I don't know the pervasiveness of adding to the standard library's tags versus say, other tooling using their own tags like easyjson:"intern".

I'm not sure how much there is to do here? Vet already flags duplicate tags: ./bar.go:5:2: struct field State repeats json tag "omitempty" also at bar.go:4, and I don't think vet can flag a field simply for being called omitempty, as that would be a false positive if I actually wanted the field to be named that.

I don't think vet can flag a field simply for being called omitempty, as that would be a false positive if I actually wanted the field to be named that.

That's the question imho. Might be the usefulness is outweighed by this drawback.

cc @mvdan

I agree with @dominikh, vet has a high standard for no false positives, so I don't think it can be added. The buggy example you shared originally would be very quickly spotted with a test or by running the code, I presume.

I'm also not sure I get the title of the issue. json:"omitempty" is perhaps confusing, but it's not an invalid tag.

Sorry for the confusion, the title was still on the notion of omitempty affecting decoding. Closing this one on the basis of not generating false positives as vet standard. Thanks for the discussion!