Golang x/tools/gopls: modernize's rangeint check is too aggressive

gopls version

➜ gopls -v version
Build info
----------
golang.org/x/tools/gopls v0.18.1
    golang.org/x/tools/gopls@v0.18.1 h1:2xJBNzdImS5u/kV/ZzqDLSvlBSeZX+pWY9uKVP7Pask=
    github.com/BurntSushi/toml@v1.4.1-0.20240526193622-a339e1f7089c h1:pxW6RcqyfI9/kWtOwnv/G+AzdKuy2ZrqINhenH4HyNs=
    github.com/google/go-cmp@v0.6.0 h1:ofyhxvXcZhMsU5ulbFiLKl/XBFqE1GSq7atu8tAmTRI=
    golang.org/x/exp/typeparams@v0.0.0-20241210194714-1829a127f884 h1:1xaZTydL5Gsg78QharTwKfA9FY9CZ1VQj6D/AZEvHR0=
    golang.org/x/mod@v0.23.0 h1:Zb7khfcRGKk+kqfxFaP5tZqCnDZMjC5VtUBs87Hr6QM=
    golang.org/x/sync@v0.11.0 h1:GGz8+XQP4FvTTrjZPzNKTMFtSXH80RAzG+5ghFPgK9w=
    golang.org/x/telemetry@v0.0.0-20241220003058-cc96b6e0d3d9 h1:L2k9GUV2TpQKVRGMjN94qfUMgUwOFimSQ6gipyJIjKw=
    golang.org/x/text@v0.22.0 h1:bofq7m3/HAFvbF51jz3Q9wLg3jkvSPuiZu/pD1XwgtM=
    golang.org/x/tools@v0.30.1-0.20250221230316-5055f70f240c h1:Ja/5gV5a9Vvho3p2NC/T2TtxhHjrWS/2DvCKMvA0a+Y=
    golang.org/x/vuln@v1.1.3 h1:NPGnvPOTgnjBc9HTaUx+nj+EaUYxl5SJOWqaDYGaFYw=
    honnef.co/go/tools@v0.5.1 h1:4bH5o3b5ZULQ4UrBmP+63W9r7qIkqJClEA9ko5YKx+I=
    mvdan.cc/gofumpt@v0.7.0 h1:bg91ttqXmi9y2xawvkuMXyvAA/1ZGJqYAEGjXuP0JXU=
    mvdan.cc/xurls/v2@v2.5.0 h1:lyBNOm8Wo71UknhUs4QTFUNNMyxy2JEIaKKo0RWOh+8=
go: go1.24.1

go env

N/A

What did you do?

Ran go run golang.org/x/tools/gopls/internal/analysis/modernize/cmd/modernize@latest -test -fix ./... on code similar to the following:

func main() {
    var i int
    for i = 0; i < 10; i++ {}
    println(i)
}

What did you see happen?

modernize transformed the code to:

func main() {
    var i int
    for i = range 10 {}
    println(i)
}

This is a functional change, since the range over int doesn't perform the final increment. This code prints 9.

What did you expect to see?

The original implementation would print 10, since the final increment occurs even if the loop body doesn't execute. I would expect to see the same behavior after applying modernize fixes.

The modernize tool should probably not apply this change if the loop variable's scope is greater than that of the loop itself (unless it can determine that the loop variable is no longer used after the loop completes).

Editor and settings

No response

Logs

No response

Comment From: adonovan

I thought we had already fixed this as #71952, and I can't reproduce it using the latest modernize on your example. Are you certain you're using the latest code. Please re-open if so.