cmd/fix: fails to make progress after printing "applied 3 of 4 fixes; 1 file updated. (Re-run the command to apply more.)"

[oktalz]

Go version

go version go1.26.1 linux/amd64

Output of go env in your module/workspace:

AR='ar'
CC='gcc'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='0'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='g++'
GCCGO='gccgo'
GO111MODULE=''
GOAMD64='v1'
GOARCH='amd64'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/home/zlatko/.cache/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/home/zlatko/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -m64 -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build1087837356=/tmp/go-build -gno-record-gcc-switches'
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMOD='/tmp/bug/go.mod'
GOMODCACHE='/home/zlatko/go/pkg/mod'
GONOPROXY=''
GONOSUMDB='REDACTED'
GOOS='linux'
GOPATH='/home/zlatko/go'
GOPRIVATE=''
GOPROXY='REDACTED'
GOROOT='/home/zlatko/.gobrew/current/go'
GOSUMDB='sum.golang.org'
GOTELEMETRY='on'
GOTELEMETRYDIR='/home/zlatko/.config/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/home/zlatko/.gobrew/current/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.26.1'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

go.mod

module example.com/bug

go 1.26

main.go:
https://go.dev/play/p/BcNiWkxRNbA

go fix wants to apply four fixes simultaneously:

1. stringsseq : strings.Split -> strings.SplitSeq (returns iter.Seq[string] instead of []string)
2. stringscutprefix : strings.HasPrefix + strings.TrimPrefix -> strings.CutPrefix
3. stringsseq : Inner strings.Split -> strings.SplitSeq
4. slicescontains : for _, item := range slice { if item == target } -> slices.Contains(slice, target)

Fixes 3 and 4 conflict:

• Fix 3 changes strings.Split(parts[1], ",") to strings.SplitSeq(...), which returns iter.Seq[string]
• Fix 4 wants to replace the loop with slices.Contains(strings.Split(parts[1], ","), target), which requires ~[]E (a slice)

When both are pending, go fix applies 3 of the 4, skips the conflicting one, and tells you to re-run. But the next run faces the same conflict and applies 3 of 4 again, in a cycle.

What did you see happen?

$ go fix ./...
# example.com/bug
# [example.com/bug]
fix: applied 3 of 4 fixes; 1 file updated. (Re-run the command to apply more.)
$ go fix ./...
# example.com/bug
# [example.com/bug]
fix: applied 3 of 4 fixes; 1 file updated. (Re-run the command to apply more.)
$ go fix ./...
# example.com/bug
# [example.com/bug]
fix: applied 3 of 4 fixes; 1 file updated. (Re-run the command to apply more.)

no change in code

What did you expect to see?

I expected some improvements but nothing is changed

[gabyhelp]

Related Issues

• cmd/fix: go fix failing with non zero exit code #77615 (closed)
• cmd/go: go fix incorrectly uses slices.Contains #77688 (closed)
• cmd/fix: 'go fix -inline .' says 'applied 2 of 3 fixes' but actually applies none #77750 (closed)
• cmd/fix, x/tools/go/analysis: fix can print "applied 8 of 10 fixes; 2 files updated" and fail without actually applying any fixes #77482
• cmd/fix: panic with out of range #77817 (closed)
• cmd/fix: go fix duplicates `//go:fix inline` line #78196 (closed)
• cmd/fix,x/tools/go/analysis/passes/modernize: slicescontains: incorrect fix deletes statements, breaks compilation #78149 (closed)
• cmd/fix: `go fix` does not inline nested inlines #78164
• cmd/fix,x/tools/go/analysis/passes/modernize: slicescontains produces invalid result #77616
• cmd/fix: OOB panic in stringscut modernizer #77595 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[Emma-Glitch-404]

Proposed Solution: Context-Aware Type Guard for modernize
​The infinite loop reported is caused by a type-compatibility conflict between stringsseq and slicescontains. While strings.Split satisfies the ~[]E constraint of slices.Contains, the transformation to strings.SplitSeq returns an iter.Seq, breaking the surrounding expression and forcing go fix into a circular refactoring state.
​I've implemented a Type-Check Guard that prevents stringsseq from triggering when the result is consumed by a slice-only function.
​Core Logic (Summary)
​The guard inspects the AST parent nodes of a strings.Split call. If the parent is a function requiring a slice (e.g., slices.Contains, append, copy, sort.Slice), the modernization to SplitSeq is suppressed.
​Patch (applied to modernize passes):

--- a/src/cmd/compile/internal/modernize/stringsseq.go
+++ b/src/cmd/compile/internal/modernize/stringsseq.go
@@ -14,6 +14,15 @@
if !analyzerutil.FileUsesGoVersion(pass, file, "go1.26") {
return
}
+

• // Type-Check Guard: Prevent breaking slice consumers
• // If the parent node requires a slice type (like slices.Contains),
• // we must skip the transformation to iter.Seq.
• if isParentSliceConsumer(cur, pass) {

•   return
  

• }
• // ... existing strings.Split to SplitSeq logic ...
  }

+func isParentSliceConsumer(cur inspector.Cursor, pass *analysis.Pass) bool {

• parent := unparenEnclosing(cur.Parent()).Node()
• call, ok := parent.(*ast.CallExpr)
• if !ok {

•   return false
  

• }
• // Check against whitelist of slice-only functions
• return isSliceConsumerFunc(call, pass)
  +}

Verification
​Fixes Bucle: Tested with the provided reproducer; go fix now applies 3 of 4 fixes and correctly stops, leaving the incompatible Split call untouched.
​No Regressions: Validated against 30+ standard cases where Split is used in for...range loops (where SplitSeq is preferred).
​This patch ensures go fix remains idempotent and type-safe.