cmd/compile: go1.22+ cmd with go.mod 1.21 generates per-loop variable when using line directive [1.26 backport]

[gopherbot]

@xieyuschen requested issue #77248 to be considered for backport to the next 1.26 minor release.

@gopherbot please open backport issues.

The issue breaks the compatible behavior mentioned in loopvar docs. It's a corner case but I believe the use case(see background) is valid

[gopherbot]

Change https://go.dev/cl/739000 mentions this issue: [release-branch.go1.24] cmd/compile: fix loopvar version detection with line directives

[prattmic]

Hi @xieyuschen, to help us assess whether this warrants a backport or not, could you clarify the background on #77248 a bit?

One problematic scenario I can imagine is:

1. Your module has go 1.21.
2. You write a buggy for loop that captures the loop variable.
3. This bug would normally be caught by tests, but because the test framework adds //line directives, the file is built with 1.22 semantics, "fixing" the bug.
4. When releasing to prod you build without //line directives, thus shipping the bug to prod.

Is this similar to the case you encountered?

Is there a particular reason this module is being intentionally held back to go 1.21, or it just happens to have not been updated?

[xieyuschen]

Hi @prattmic , the steps are correct and the exact issue I encountered.

Is there a particular reason this module is being intentionally held back to go 1.21, or it just happens to have not been updated?

Let me add on some background: the scope could be split into 3 parts:

• user: the codebase for their service(go 1.21 inside go.mod)
• toolchain maintainer(me): we have a workflow to upgrade go version for services via internal toolchain as we control the whole build process(which wraps go build).
• test framework: insert //line directive.

The go 1.21 is hold because it's owned by user, not me. My goal is help to upgrade go version used to build for all my toolchain users without requiring their action. In most of cases it works fine, thanks to the go compatiblity promise🎉.

But it's not feasible for me to push them upgrading go line inside go.mod as it requires code change and a full release process. Our temporary solution is to ask test framework remove //line directive, but I believe it's nice to have a backport.

[dmitshur]

With the release of Go 1.26.0, the two latest supported major Go releases are 1.26 and 1.25 per the Go release policy. Retargeting this 1.24 backport issue to track the 1.26 backport instead.