Closed dominiquelefevre closed 1 month ago
Hi, is anybody out here to take a look at the patch? @denisvmedia, @chavacava?
Hi @dominiquelefevre, thanks for the PR ! I' ll try to review before the weekend.
Thanks @dominiquelefevre !
@chavacava could you please tag a new release so that I can make a PR to golangci-lint to use the up-to-date revive?
Let me step out the data race fix for a moment and go back to the initial needs described in the ticket
How different is the feature brought by this PR from https://github.com/karamaru-alpha/copyloopvar created by @karamaru-alpha
And added to golangci-lint via https://github.com/golangci/golangci-lint/pull/4382
I'm glad so see it added to revive if it's the same feature but it could have consequence for copyloopvar or golangci projects maybe
Before go 1.22, all iterations of a loop shared their loop variables. If you created a function inside the loop, all those functions would capture the same one variable. Hence, if you iterated over a collection and wanted to create a function for every item in a collection, you needed to make copies of loop variables manually.
Starting with 1.22, the go compiler does that for you. Thus,
This PR addresses 1 and removes false reports about errors introduced by aliasing. Copyloopvar addresses 2 and warns about extraneous copies.
Thank you @dominiquelefevre it's way clearer now.
@chavacava This PR will create a performance regression because go list
is expensive and will be called on each package (even when range-val-address
is not used).
"Funny thing", the regression impacts all the rules except range-val-address
because this rule is skipped with go1.22.
It will be a performance regression for revive and for golangci-lint.
For golangci-lint, a way to define the Go version externally to bypass the go list
is a solution.
I don't know enough about the revive design to propose a solution for revive.
We encountered the same problem with gosec https://github.com/golangci/golangci-lint/issues/4735
Also, the implementation has a bug with Go workspaces:
can't parse the output of go list: invalid character '{' after top-level value
Inside a Go workspace, go list
always returns all the modules, not just the current module.
As a reference, a working implementation: https://github.com/golangci/modinfo/blob/main/module.go
FYI, the issue comment (https://github.com/golang/go/issues/44753#issuecomment-790089020), used as a reference inside the PR, is outdated since Go workspace (go1.18).
I will open a dedicated issue. -> https://github.com/mgechev/revive/issues/995
Go 1.22 has changed the behaviour of for loops. Every iteration makes new loop variables. It is now safe to take their addresses because they are guaranteed to be unique. Similarly, it is now safe to capture loop variables in functions.