*: clean up remaining golangci-lint failures #2962
Conversation
Most of these were false positives or cases where we want to ignore the lint, but the change to the BPF generation is actually useful. Signed-off-by: Aleksa Sarai <[email protected]>
|
Should we give warnings for all lint errors? I can disable that flag again, but I noticed that some of the new errors were added in PRs that I made after we enabled the CI check -- so I wonder if the |
It seems that golangci-lint didn't warn us about new lint errors that were added after we enabled it, so just run the full thing and give us all the errors on every PR run -- as long as we keep master lint-clean it doesn't matter whether we set this or not. Signed-off-by: Aleksa Sarai <[email protected]>
| @@ -96,7 +96,7 @@ func parseStat(data string) (stat Stat_t, err error) { | |||
| // one (PID) and two (Name) in the paren-split. | |||
| parts = strings.Split(data[i+2:], " ") | |||
| var state int | |||
| fmt.Sscanf(parts[3-3], "%c", &state) | |||
| fmt.Sscanf(parts[3-3], "%c", &state) //nolint:staticcheck // "3-3" is more readable in this context. | |||
There was a problem hiding this comment.
I have a fix for this #2696 (which started as a fix for this linter issue but ended up as a rewrite of parseStat to be 7x faster and more error-prone).
The idea was to drop this golangci-lint flag as long as the master branch is clean of any existing issues, which is what this PR does, so yes, sure. And yes indeed, I occasionally saw it skip some issues, probably because their "limit the scope to what this PR brings" algo is not perfect for some reason. |
Most of these were false positives or cases where we want to ignore the
lint, but the change to the BPF generation is actually useful.
Follow-up to #2781
Signed-off-by: Aleksa Sarai [email protected]