feat: add noloopclosure

[fatanugraha]

noloopclosure is a linter that disallow reference capture of loop variable inside of a closure.

https://github.com/fatanugraha/noloopclosure

[boring-cyborg]

Hey, thank you for opening your first Pull Request !

[CLAassistant]

All committers have signed the CLA.

[ldez]

In order for a pull request adding a linter to be reviewed, the linter and the PR must follow some requirements.

Pull Request Description

• It must have a link to the linter repository.
• It must provide a short description about the linter.

Linter

• It must not be a duplicate of another linter or a rule of a linter. (the team will help to verify that)
• It must have a valid license and the file must contain the required information by the license, ex: author, year, etc.
• The linter repository must have a CI and tests.
• It must use go/analysis.
• It must have a valid tag, ex: v1.0.0, v0.1.0.
• It must not contain init().
• It must not contain panic(), log.fatal(), os.exit(), or similar.
• It must not have false positives/negatives. (the team will help to verify that)
• It must have tests inside golangci-lint.

The Linter Tests Inside Golangci-lint

• They must have at least one std lib import.
• They must work with T=<name of the linter test file>.go make test_linters. (the team will help to verify that)

.golangci.reference.yml

• The linter must be added to the list of available linters (alphabetical case-insensitive order).
  • enable and disable options
• If the linter has a configuration, the exhaustive configuration of the linter must be added (alphabetical case-insensitive order)
  • The values must be different from the default ones.
  • The default values must be defined in a comment.
  • The option must have a short description.

Others Requirements

• The files (tests and linter) inside golangci-lint must have the same name as the linter.
• The .golangci.yml of golangci-lint itself must not be edited and the linter must not be added to this file.
• The linters must be sorted in the alphabetical order (case-insensitive) in the Manager.GetAllSupportedLinterConfigs(...) and .golangci.example.yml.
• The load mode (WithLoadMode(...)):
  • if the linter doesn't use types: goanalysis.LoadModeSyntax
  • goanalysis.LoadModeTypesInfo required WithLoadForGoAnalysis() in the Manager.GetAllSupportedLinterConfigs(...)
• The version in WithSince(...) must be the next minor version (v1.X.0) of golangci-lint.

Recommendations

• The linter should not use SSA. (currently, SSA does not support generics)
• The linter repository should have a readme and linting.
• The linter should be published as a binary. (useful to diagnose bug origins)

---

The golangci-lint team will edit this comment to check the boxes before and during the review.

This checklist does not imply that we will accept the linter.

[ldez]

Hello,

I feel like a duplicate of exportloopref or looppointer

[fatanugraha]

Hi @ldez I checked both linters already and it seems that those linters only check whether the loop variable is captured using & operator or not.

This new linter checks whether the loop variable is captured using closure or not (not necessarily a pointer) -- to avoid accidental reference because of closures.

It will check whether a loop has function literal on it and check whether the function literal's body referenced the loop variable or not (similar to go vet's loopclosure).

For example, this linter will complain that i is a loop variable in L3

for i := 0; i < 5; i++ {
  go (func() { fmt.Println(i) })() // L3
}

I tried both linters that you mentioned for code snippet above and it passes.

[ldez]

We refused looppointer because of the number of false-positives, you will have to prove that don't have the same problem as looppointer

[fatanugraha]

@ldez this linter is way simpler than looppointer.

What it does is basically:

1. check all loops
2. check whether the loop has *ast.FuncLit on it
3. check the object (types.Object) of all *ast.Ident on the body of that *ast.FuncLit and see whether it's the same as the enclosing loop variable object.

The implementation is basically the striped-down version of go vet's loopclosure.

[fatanugraha]

We refused looppointer because of the number of false-positives, you will have to prove that don't have the same problem as looppointer

Hi @ldez what kind of proof do you require for this one?

[hawkingrei]

@ldez We are from TiDB. We have used noloopclosure in our repo. It is a really good linter. we don't find any false positives from noloopclosure.

I hope it can be merged into master.

[fatanugraha]

After reading this similar issue more thoroughly, I think this linter will have the same issue that looppointer have.

These two linters will reject a valid Go code that might or might not cause a bug. The idea of these two linter is to disallow a certain practices that might introduce the bug in the first place (so it will be impossible to introduce the bug). So I wouldn't call them a false-positive (from the linter's perspective) since that's the whole point of these two linters.

Personally I think this linter will complement looppointer nicely to make sure that user's code is safe when they're migrating to Go 2 (if the Go team decided to go with this proposal) so I think these two linters can still provide some value to golangci-lint users (even though they're very opinionated).

@hawkingrei Having said all of that, I don't think this linter will be merged to master anytime soon since it cause issues to users that enables all the linter via enable-all flag. The best that we can do is to run them without golangci-lint.

@ldez Feel free to close this issue if you think we shouldn't merge this to master. Thanks!

[ldez]

@ldez Feel free to close this issue if you think we shouldn't merge this to master. Thanks!

Closed for now