update to go 1.23

[crazy-max]

similar to:

• update to go 1.23 moby/buildkit#5492
• hack: update golangci-lint to 1.61 moby/buildkit#5314
• Update gopls and protolint moby/buildkit#5484

[thaJeztah]

Can you update the order of the commits?

• The fix golangci-lint issues should probably be first
• then the "update golangci", and then the other ones.
• oh, and the G115 # integer overflow conversion (TODO: verify these) should be in the second one (as it's related to the golangci-lint update)

[thompson-shaun]

I think everything requested was addressed @thaJeztah - are we OK to merge this one?

[tonistiigi]

Why 61 in 62 is the latest?

[crazy-max]

Was released after my PR got opened 😅

[thaJeztah]

As you're updating; might as well update this one as well (if it helps; I didn't need to make changes in moby when updating)

[crazy-max]

Done

[thaJeztah]

Looks like the first commit doesn't work; I'm guessing the older golangci-lint is not compatible with go1.23, so to be "correct", the go bump should probably go after the golangci-lint bump

[crazy-max]

Looks like the first commit doesn't work; I'm guessing the older golangci-lint is not compatible with go1.23, so to be "correct", the go bump should probably go after the golangci-lint bump

Done

[thaJeztah]

LGTM

[crazy-max]

Ah fixes needed with latest golangci-lint 1.62 actually: https://github.com/docker/buildx/actions/runs/11930900417/job/33252637019?pr=2782#step:5:368

#19 [lint 1/1] RUN --mount=target=/go/src/github.com/docker/buildx     --mount=target=/root/.cache,type=cache,id=lint-cache-darwin/arm64     xx-go --wrap &&     golangci-lint run
#19 92.91 driver/remote/driver.go:51:8: lostcancel: the cancel function returned by context.WithTimeoutCause should be called, not discarded, to avoid a context leak (govet)
#19 92.91 		ctx, _ := context.WithTimeoutCause(cancelCtx, 20*time.Second, errors.WithStack(context.DeadlineExceeded))
#19 92.91 		     ^
#19 92.91 builder/builder.go:526:14: lostcancel: the cancel function returned by context.WithTimeoutCause should be called, not discarded, to avoid a context leak (govet)
#19 92.91 	timeoutCtx, _ := context.WithTimeoutCause(cancelCtx, 20*time.Second, errors.WithStack(context.DeadlineExceeded))
#19 92.91 	            ^
#19 92.91 commands/inspect.go:39:14: lostcancel: the cancel function returned by context.WithTimeoutCause should be called, not discarded, to avoid a context leak (govet)
#19 92.91 	timeoutCtx, _ = context.WithTimeoutCause(timeoutCtx, 20*time.Second, errors.WithStack(context.DeadlineExceeded))
#19 92.91 	            ^
#19 92.91 commands/ls.go:62:14: lostcancel: the cancel function returned by context.WithTimeoutCause should be called, not discarded, to avoid a context leak (govet)
#19 92.91 	timeoutCtx, _ = context.WithTimeoutCause(timeoutCtx, 20*time.Second, errors.WithStack(context.DeadlineExceeded))
#19 92.91 	            ^
#19 92.91 commands/rm.go:154:14: lostcancel: the cancel function returned by context.WithTimeoutCause should be called, not discarded, to avoid a context leak (govet)
#19 92.91 	timeoutCtx, _ = context.WithTimeoutCause(timeoutCtx, 20*time.Second, errors.WithStack(context.DeadlineExceeded))
#19 92.91 	            ^

Seems a false positive though as we are handling cancel in parent already. Related to #2798

[crazy-max]

Getting this one in