-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
[ci] Add errcheck
to golangci-lint
#7996
Conversation
@ajm188 AFAIK, in draft mode also the CI tests run :) |
huh! i have a vague memory of turning a PR back to draft mode to debug some tests and none of the CIs were running. happy to be wrong though! |
eefb8a6
to
8dca6f7
Compare
errcheck
to golangci-linterrcheck
to golangci-lint
@@ -40,11 +40,13 @@ func List() *cobra.Command { | |||
out = rules | |||
} | |||
} else { | |||
out = rules.Find(listOptName) | |||
if listOptNamesOnly && out != nil { | |||
rule := rules.Find(listOptName) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See 6ab6b47 for why this change
@@ -283,7 +283,7 @@ func (c *Collection) Append(m Metric) error { | |||
c.Lock() //nolint SA5011: possible nil pointer dereference | |||
defer c.Unlock() //nolint SA5011: possible nil pointer dereference | |||
// we don't want to add nil metrics | |||
if c == nil { | |||
if c == nil { //nolint SA5011: redundant nil pointer check - maybe this was supposed to check if m == nil ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@shlomi-noach calling your particular attention to this line; I think this should be checking if m == nil
(since we checked c == nil
just before locking above) but wanted to confirm with you first.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ajm188 I believe you're right, this should be m == nil
. Took me a while to understand why I have no recollection of this code, it was a contribution and I'm not too familiar with it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@@ -283,7 +283,7 @@ func (c *Collection) Append(m Metric) error { | |||
c.Lock() //nolint SA5011: possible nil pointer dereference | |||
defer c.Unlock() //nolint SA5011: possible nil pointer dereference | |||
// we don't want to add nil metrics | |||
if c == nil { | |||
if c == nil { //nolint SA5011: redundant nil pointer check - maybe this was supposed to check if m == nil ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ajm188 I believe you're right, this should be m == nil
. Took me a while to understand why I have no recollection of this code, it was a contribution and I'm not too familiar with it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
A couple of things:
- Review the
nolint
directives, perhaps some of them should change to ignore the return value instead - It will be nice to update the version in https://github.com/vitessio/vitess/blob/main/misc/git/hooks/golangci-lint
@@ -85,7 +85,7 @@ func main() { | |||
startMsg := fmt.Sprintf("USER=%v SUDO_USER=%v %v", os.Getenv("USER"), os.Getenv("SUDO_USER"), strings.Join(os.Args, " ")) | |||
|
|||
if syslogger, err := syslog.New(syslog.LOG_INFO, "vtctl "); err == nil { | |||
syslogger.Info(startMsg) | |||
syslogger.Info(startMsg) // nolint:errcheck |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: why not _ = ...
instead of nolint
?
Signed-off-by: Andrew Mason <[email protected]>
Signed-off-by: Andrew Mason <[email protected]>
Signed-off-by: Andrew Mason <[email protected]>
Signed-off-by: Andrew Mason <[email protected]>
This is an often-surprising Go quirk, so I will explain a bit: An interface has two components: the concrete type, and the value. If both of these are `nil`, then the interface is equal to `nil`. If the concrete type is non-nil, even if the value for that type is nil, then the interface is non-nil. For a toy example, see: https://play.golang.org/p/0uLrBekVg_y. In this specific case, we were taking `rules.Find`, which returns `*rules.Rule` and assigning that to a variable with the type of `interface{}`. Since we have a concrete type for the interface, the `out != nil` check will never be false. The fix here is to use a second variable, which will have the concrete type, and check if the pointer is nil, which is what we actually wanted here. Signed-off-by: Andrew Mason <[email protected]>
Signed-off-by: Andrew Mason <[email protected]>
…lint directives Signed-off-by: Andrew Mason <[email protected]>
Signed-off-by: Andrew Mason <[email protected]>
Signed-off-by: Andrew Mason <[email protected]>
Still need to update the version we download in the hook (if the binary doesn't exist locally). vitess/misc/git/hooks/golangci-lint Line 28 in 8b7a4cb
Also, do we need to announce/warn people in #developers that they will need to upgrade their installed version of the linter? |
Signed-off-by: Andrew Mason <[email protected]>
yeah, i was planning to post in #developers after i merged! |
Description
This PR enables the
errcheck
linter as part of thegolangci-lint
linter suite, and then sets up a bunch of configs to allow us to progressively enable this linter on more and more parts of the codebase.To make this work, I needed to bump the version of
golangci-lint
tov1.39.0
, since earlier versions were not correctly working with theerrcheck_excludes.txt
file. I can't go all the way to the latest version (v1.40.1
) because that starts to complain about stuff in the fuzz tests, and I didn't want to touch those in this change haha.After I got the config into a working state, I then moved through and fixed up a bunch of the now-complaining
errcheck
failures. I stuck to packages that had relatively few failures, and to errcheck violations that I thought would be pretty uncontroversial to fix. The rest of the packages I've left as ignored in our.golangci.yml
config, and as we gradually fix those instances we can remove those entries from the config.Related Issue(s)
Closes #8222
Checklist
Deployment Notes