x/tools/go/analysis/passes/modernize: RangeIntAnalyzer fix breaks code if type of limit expression is type parameter constrained by multiple integer types

[mwriter]

Sample code:

type Integer interface {
    ~int | ~uint
}

func Loop[I Integer](n I) {
    var i I
    for i = 0; i < n; i++ {    // for loop can be modernized using range over int
        println(i)
    }
}

Change the code according to the suggestion and of course get a real error:

func Loop[I Integer](n I) {
    var i I
    for i = range n {    // cannot range over n (variable of type I constrained by Integer): int and uint have different underlying types
        println(i)
    }
}

[gabyhelp]

Related Issues

• x/tools/go/analysis/passes/modernize: doesn't convert 'for i := 0; i < 10; i += 1 {}' #76977 (closed)
• cmd/fix, x/tools/go/analysis/passes/modernize: bad rangeint rewriting #77034 (closed)
• x/tools/gopls/internal/analyze/modernize: rangeint: transformation introduces invalid type #73037 (closed)
• x/tools/gopls/internal/analysis/modernize: rangeint suggests changes that alter some programs' semantics #75289 (closed)
• x/tools/gopls: modernize's rangeint check is too aggressive #74295 (closed)
• x/tools/gopls/internal/analysis/modernize: rangeint should be silent when RHS of 'i < limit' depends on loop var #72726 (closed)
• x/tools/gopls/internal/analysis/modernize: range over int rule doesn't consider potential slice appends #73022 (closed)
• x/tools/gopls/internal/analysis/modernize: rangeint: transformation unsound when loop variable is defined outside loop #73009 (closed)
• x/tools/gopls/internal/analysis/modernize: rangeint generates correct but not idiomatic transformation #71725 (closed)
• cmd/fix,x/tools/go/analysis/passes/modernize: rangeint uses target platform's type in the range expression, breaking other platforms #77691 (closed)

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

[adonovan]

The operand of a range loop may not be a type parameter constrained by multiple distinct integer types:

func f[I int | uint](n I) {
	for range n { // error: cannot range over n (variable of type I constrained by int | uint): int and uint have different underlying types
	}
}

Yet another way in which the trivial rangeloop analyzer is harder than it looks!

We should fix the analyzer to recognize this case.

[gopherbot]

Change https://go.dev/cl/764660 mentions this issue: go/analysis/passes/modernize: rangeint: handle type parameter constraints