You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
x/tools: support for go1.28's rejection of string(int) conversions #81760
Since #3939 was accepted, we need to ensure the tools are up to date. This issue tracks that work. I don't think it should be much, but a few items come to mind:
The inliner now has to deal with the possibility that inlining a function body from an file using an older dialect of Go, in which string(int) conversions are valid, into a file using a newer version, may break. (It already handles the converse problem.)
The stringintconv analyzer will need auditing.
We'll need a modernizer that preserves the existing behavior. (stringintconv offers two fixes, between which the user must choose, and for this reason it is omitted from the go fix suite. If its default fix is behavior preserving, then it can be enabled by default.)
One problem: if we add a fixer to go fix in go1.28, the same release that disallows the very construct the fixer looks for, then it won't be able to fix go1.28 code; you would need to apply the fix to go1.27 code before upgrading your go.mod file. I suppose we could make the fixer accept ill-typed code (Analyzer.RunDespiteErrors), so long as the error is exactly "string(int) no longer allowed". That's a risky strategy because type errors are hard to distinguish, and errors in dependencies undermine all kinds of invariants that would lead to subtle crashes. We definitely wouldn't want most modernizers to set this flag. Perhaps that's a good enough compromise in this narrow case, but in general it would be better if we had a 1 cycle grace period between fixing a deprecated feature and removing it.
Activity
adonovan commentedon Sep 28, 2026
One problem: if we add a fixer to
go fixin go1.28, the same release that disallows the very construct the fixer looks for, then it won't be able to fix go1.28 code; you would need to apply the fix to go1.27 code before upgrading your go.mod file. I suppose we could make the fixer accept ill-typed code (Analyzer.RunDespiteErrors), so long as the error is exactly "string(int) no longer allowed". That's a risky strategy because type errors are hard to distinguish, and errors in dependencies undermine all kinds of invariants that would lead to subtle crashes. We definitely wouldn't want most modernizers to set this flag. Perhaps that's a good enough compromise in this narrow case, but in general it would be better if we had a 1 cycle grace period between fixing a deprecated feature and removing it.gopherbot commentedon Sep 28, 2026
Change https://go.dev/cl/840805 mentions this issue:
go/analysis/passes/stringintconv: make first fix behavior-preservinggopherbot commentedon Sep 28, 2026
Change https://go.dev/cl/840806 mentions this issue:
gopls/internal/golang: quick fixes for go1.28 string(int) errorgopherbot commentedon Sep 28, 2026
Change https://go.dev/cl/840886 mentions this issue:
go/analysis/passes/stringintconv: use Cursor; split out checkCallgopherbot commentedon Sep 28, 2026
Change https://go.dev/cl/840885 mentions this issue:
go/analysis/passes/stringintconv: make tests run under go1.28go/analysis/passes/stringintconv: make tests run under go1.28
go/analysis/passes/stringintconv: use Cursor; move logic to intconv
prattmic commentedon Sep 29, 2026
cc @golang/tools-team
go/analysis/passes/stringintconv: make first fix behavior-preserving
gopls/internal/golang: quick fixes for go1.28 string(int) error