cmd/vet: Always errors if printf-style function from an imported package is used #14754
Comments
spenczar
changed the title
|
As I look at this, it seems that reverting is the only sane way forward. Calculating the signatures of the functions (as we do now) makes the code more complex with very little benefit, since the original change was attempting to support libraries which use custom printf-style functions, like gRPC's Errorf. If we can't effectively vet imported functions, we can't vet those, and we may as well return to a hardcoded list. So, I'd like to revert, but I want someone with more experience with the ast and vet packages to weigh in to correct me if it's possible to follow imports simply. |
|
Vet could inspect function arguments by searching for the fisrt string literal and assume this is format string. There is no need in function type knowledge in this case. |
|
CL https://golang.org/cl/21023 mentions this issue. |
This is a regression pointed out by @valyala in #12294 (comment).
https://golang.org/cl/20163 does not work. vet is unable to find the signature of any functions or methods which aren't defined in the current package being vetted, so it flags these functions/methods as always having 'no formatting directive'.
The ideal answer, from a vet user's perspective, would seem to be to have vet import those packages and look up their function signature, but (as far as I can understand) that would expand what vet does pretty dramatically and could make it slower. Right now, it doesn't seem to have a build context, so importing isn't straightforward. I would be happy to be wrong about this, though!
If I'm not wrong and importing is not in the cards, then the right thing might be to just revert the changes introduced in https://golang.org/cl/20163, or we could just assume sane defaults if we're unable to find the function signature, using the old, pre-CL20163
printfListwhich hardcoded the expected position of the format param.The text was updated successfully, but these errors were encountered: