-
Notifications
You must be signed in to change notification settings - Fork 389
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
🌱 Bump golangci-lint, remove staticcheck #3208
Conversation
On-behalf-of: @SAP christoph.mewes@sap.com
On-behalf-of: @SAP christoph.mewes@sap.com
On-behalf-of: @SAP christoph.mewes@sap.com
On-behalf-of: @SAP christoph.mewes@sap.com
On-behalf-of: @SAP christoph.mewes@sap.com
On-behalf-of: @SAP christoph.mewes@sap.com
On-behalf-of: @SAP christoph.mewes@sap.com
On-behalf-of: @SAP christoph.mewes@sap.com
On-behalf-of: @SAP christoph.mewes@sap.com
@@ -162,8 +162,6 @@ func TestServiceAccounts(t *testing.T) { | |||
}}, | |||
} | |||
for i, ttc := range testCases { | |||
i := i |
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.
I remember reading some go release notes but cant find any about this. We don't need this anymore, right? Or what is the reasons to removing these?
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.
its a closure thing with variables... Still confused why we removing this?
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.
Loop variables are copies since Go 1.22, so creating scoped copies is not necessary anymore.
See also https://go.dev/blog/go1.22#language-changes
This is what the new copyloopvar linter detects.
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.
Leaving final approval to @mjudeikis.
LGTM label has been added. Git tree hash: 839fb75d377d658c015a8b0c13b7e04752de89e0
|
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mjudeikis The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Summary
This is some housekeeping for our linters.
Originally, the idea behind running staticcheck standalone was that "golangci-lint should find deprecation, but it doesn't work" (in Introduce staticcheck linter for deprecations #1798). I checked and could not immediately see deprecated code that golangci-lint doesn't find by itself.
Additionally, Introduce staticcheck linter for deprecations #1798 doesn't even enable the necessary check in staticcheck. Instead we configured:
Both of these things can be accomplished using
revive
. However we have to lower the minimum confidence level from 0.8 to 0.6 to surface these issues correctly. staticcheck (the standalone binary) has some additional smarts and produces fewer false positives because it recognizes code identifiers in error strings. However a few //nolint comments are to me an acceptable downside, compared to keeping a dedicated linter around.A whole bunch of functions in our SDK implicitly do a
fmt.Sprintf()
, which newer golangci-lint versions are complaining about if non-constant format strings are used. I pondered multiple solutions, but ultimately chose the simplest one that doesn't cause an API break (by callingMarkFalse(reason)
now asMarkFalse("%s", reason)
). Other options would be possible, like introducing new functions (MarkFalse
andMarkFalsef
) or removing the sprintf functionality alltogether, however since it's part of the SDK package, I feared an API break.Release Notes