Bump honnef.co/go/tools from 0.4.0 to 0.5.1

[dependabot]

Bumps honnef.co/go/tools from 0.4.0 to 0.5.1.

Release notes

Sourced from honnef.co/go/tools's releases.

Staticcheck 2024.1.1 (v0.5.1)

This release fixes the detection of the used Go version when Go was compiled with experimental features such as rangefunc or boringcrypto (#1586).

Staticcheck 2024.1 (v0.5.0)

Backwards incompatible changes

Staticcheck 2024.1 contains the following backwards incompatible changes:

• The keyify utility has been removed. The recommended alternative is gopls.
• staticcheck -merge now exits with a non-zero status if any problems have been found.

Improved Go 1.22 support

This release updates Staticcheck’s database of deprecated standard library APIs to cover the Go 1.22 release. Furthermore, checks have been updated to correctly handle the new “for” loop variable scoping behavior as well as ranging over integers.

Added Go 1.23 support

Staticcheck 2024.1 has full support for iterators / range-over-func. Furthermore, SA1015 will skip any code targeting Go 1.23 or newer, as it is now possible to use time.Tick without leaking memory.

Improved handling of Go versions

Go 1.21 more rigorously defined the meaning of the go directive in go.mod files, as well as its interactions with //go:build go1.N build constraints. The go directive now specifies a minimum Go version for the module. Furthermore, it sets the language version that is in effect, which may change the semantics of Go code. For example, before Go 1.22, loop variables were reused across iterations, but since Go 1.22, loop variables only exist for the duration of an iteration. Modules that specify go 1.22 will use the new semantics, while modules that specify an older version will not.

Individual files can both upgrade and downgrade their language version by using //go:build go1.N directives. In a module that requires Go 1.22, a file specifying Go 1.21 will experience the old loop variable semantics, and vice versa. Because the Go module as a whole still specifies a minimum version, even files specifying an older version will have access to the standard library of the minimum version.

Staticcheck 2024.1 takes all of this into consideration when analyzing the behavior of Go code, when determining which checks are applicable, and when making suggestions. Older versions of Staticcheck were already aware of Go versions, but 2024.1 works on a more fine-grained, per-file basis, and differentiates between the pre- and post-1.21 semantics of the go directive.

The -go command line flag continues to exist. It will override any module-based version selection. This is primarily useful for Go modules that target older Go versions (because here, the go directive didn’t specify a minimum version), or when working outside of Go modules.

To prevent misinterpreting code, Staticcheck now refuses to analyze modules that require a version of Go that is newer than that with which Staticcheck was built.

Checks

New checks

The following checks have been added:

• SA1031 flags overlapping destination and source slices passed to certain encoding functions.
• SA1032 flags calls to errors.Is where the two arguments have been swapped.
• SA4032 flags impossible comparisons of runtime.GOOS and runtime.GOARCH based on the file’s build tags.
• SA6006 flags io.WriteString(w, string(b)) as it would be both simpler and more efficient to use w.Write(b).
• SA9009 flags comments that look like they intend to be compiler directives but which aren’t due to extraneous whitespace.

Changed checks

The following checks have been improved:

• QF1001 no longer panics on expressions involving “key: value” pairs (issue 1484).
• S1008 now understands that some built-in functions never return negative values. For example, it now negates len(x) > 0 as len(x) == 0 (issue 1422).
• S1009 now flags unnecessary nil checks that involve selector expressions (issue 1527).
• S1017 no longer flags if else branches (issue 1447).

... (truncated)

Commits

• 56172d4 Version 2024.1.1 (v0.5.1)
• c972610 website: add 2024.1.1 release notes
• 6052711 go/loader: handle experimental features in version detection
• 516152d analysis/lint/testutil: unset GO111MODULE in test
• d6ea187 Version 2024.1
• f2c1fda website: finalize 2024.1 release notes
• dcae6e2 lintcmd: file names are optional in error positions
• 2cef146 lintcmd: panic with the right message when we can't parse a position
• 0636bca go/ir: actually build blank functions
• 34db56d Version 2024.1rc1 (v0.5.0-rc.1)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[k8s-ci-robot]

Hi @dependabot[bot]. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: dependabot[bot]
Once this PR has been reviewed and has the lgtm label, please assign adrianludwin for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle stale
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale