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
cmd/vet: mismatch between Printf checks and actual behaviour #27672
Comments
/cc @mvdan |
Another false negative:
|
One more false negative:
|
Another false positive, presumably because the check is confused by the Error method it can't call. fmt.Printf is fine with that though, as long as the concrete type is a string. https://play.golang.org/p/qAs0Ye8atHL |
Thanks for the ping - I might have a look at this during the current cycle. |
Change https://golang.org/cl/147758 mentions this issue: |
I've filed an issue about the second case in the original comment, as I think vet is technically doing what fmt documents. |
Change https://golang.org/cl/147997 mentions this issue: |
fmt's godoc reads: For compound objects, the elements are printed using these rules, recursively, laid out like this: struct: {field0 field1 ...} array, slice: [elem0 elem1 ...] maps: map[key1:value1 key2:value2 ...] pointer to above: &{}, &[], &map[] That is, a pointer to a struct, array, slice, or map, can be correctly printed by fmt if the type pointed to can be printed without issues. vet was only following this rule for pointers to structs, omitting arrays, slices, and maps. Fix that, and add tests for all the combinations. Updates #27672. Change-Id: Ie61ebe1fffc594184f7b24d7dbf72d7d5de78309 Reviewed-on: https://go-review.googlesource.com/c/147758 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Alan Donovan <adonovan@google.com>
Pointers to compound objects (structs, slices, arrays, maps) are only followed by fmt if the pointer is at the top level of an argument. This is to minimise the chances of fmt running into loops. However, vet did not follow this rule. It likely doesn't help that fmt does not document that restriction well, which is being tracked in #28625. Updates #27672. Change-Id: Ie9bbd9b974eda5ab9a285986d207ef92fca4453e Reviewed-on: https://go-review.googlesource.com/c/147997 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Alan Donovan <adonovan@google.com>
This false positive seems related:
It seems like (If it's not related, I can open another bug) |
I don't intend to work more on vet during this cycle, so I'm unassigning myself in case someone else wants to continue the work. Right now, only the two bugs in the original post are fixed; the other four aren't fixed yet, assuming they're not duplicates. |
/cc @alandonovan |
Related: |
What version of Go are you using (
go version
)?go version go1.11 linux/amd64
What did you do?
What did you expect to see?
Vet to accept the first Printf call and to flag the second one
What did you see instead?
Vet flags the first call and accepts the second one
The text was updated successfully, but these errors were encountered: