-
Notifications
You must be signed in to change notification settings - Fork 17.6k
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
log/slog: add vet checks for variadic ...any inputs #59407
Comments
CC @jba |
Thanks, @AndrewHarrisSPU, for adding this proposal. I intended it to be part of the main proposal (#56345) but didn't include it. I think Rule 1 alone is the right choice. Rule 2 would get in the way of perfectly fine code. |
Rule 1 is the vet way. Rule 2 is not (vet eschews false positives). |
This proposal has been added to the active column of the proposals project |
Based on the discussion above, this proposal seems like a likely accept. |
No change in consensus, so accepted. 🎉 |
Change https://go.dev/cl/487475 mentions this issue: |
This was implemented and shipped with Go 1.21. |
The passing of
...any
input parameters to a number of functions and methods is a key feature of theslog
package, with ~20 instances that convertargs ...any
to slices ofAttr
s. These argument lists ask for a particular sequencing ofstring
keys,any
values, orAttr
arguments. At run time, malformed lists emit!BADKEY
keys rather than anything more fatal. This is reminiscent of howfmt.Printf
can emit disrupted output when formatting verbs don't match arguments. Analysis undergo vet
exists for this kind offmt.Printf
scenario. Similar tooling forslog
could be developed.Two rules that could be applied by analysis:
Rule 1 When arguments are given directly to a
slog
function acceptingargs ...any
, malformed calls that would otherwise result in a "!BADKEY" constant are flagged. For example,A strong, laudable example of prior art here is given in a package
loggercheck
from @timonwong, in a checker of `zapcore.Fields.Rule 2 Disallow arguments that are splatted into a
slog
function acceptingargs ...any
This rule generates false positives and asks some code to be more verbose than it would be otherwise, but rejects any code that can't be statically determined to be well formed by the first rule. For example:
One question I'd like to raise with this proposal: is
go vet
tooling appropriate?If so, another question is: what rules make sense? Rule 1 alone seems unlikely to generate false positives, and does a fair amount to catch malformed logging calls. Rule 2 alone would be unusual. Rule 1+2 is more adventurous than just rule 1 - it's tight enough to raise different questions, but seems to make "!BADKEY" in output highly unlikely.
Any
go vet
analysis is well qualified by this sentence from vet documentation:The text was updated successfully, but these errors were encountered: