Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add gobreakselectinfor linter #4924

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

Add gobreakselectinfor linter #4924

wants to merge 4 commits into from

Conversation

rnben
Copy link

@rnben rnben commented Aug 17, 2024

The Go linter go-break-select-in-for checks that break statement inside select statement inside for loop.

For example, in myFunc the break may want to exit the outer for loop, but it doesn't work as expected.

func myFunc() {
    for {
        select {
        case <-ch:
            break // should be careful
        }
    }
}

@ldez

This comment was marked as outdated.

@ldez

This comment was marked as outdated.

@ldez ldez closed this Aug 17, 2024
@ldez ldez added declined linter: new Support new linter labels Aug 17, 2024
@rnben

This comment was marked as outdated.

@ldez ldez reopened this Aug 17, 2024
@ldez
Copy link
Member

ldez commented Aug 17, 2024

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

  • The CLA must be signed

Pull Request Description

  • It must have a link to the linter repository.
  • It must provide a short description of 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 (AGPL is not allowed), and the file must contain the required information by the license, ex: author, year, etc.
  • It must use Go version <= 1.21
  • 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().
  • It must not contain log.Fatal(), os.Exit(), or similar.
  • It must not modify the AST.
  • 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 have integration tests without configuration (default).
  • They must have integration tests with configuration (if the linter has a configuration).

.golangci.next.reference.yml

  • The file .golangci.next.reference.yml must be updated.
  • The file .golangci.reference.yml must NOT be edited.
  • The linter must be added to the lists 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 lintersdb/builder_linter.go and .golangci.next.reference.yml.
  • The load mode (WithLoadMode(...)):
    • if the linter uses goanalysis.LoadModeSyntax -> no WithLoadForGoAnalysis() in lintersdb/builder_linter.go
    • if the linter uses goanalysis.LoadModeTypesInfo, it requires WithLoadForGoAnalysis() in lintersdb/builder_linter.go
  • The version in WithSince(...) must be the next minor version (v1.X.0) of golangci-lint.
  • WithURL() must contain the URL of the repository.

Recommendations

  • The file jsonschema/golangci.next.jsonschema.json should be updated.
  • The file jsonschema/golangci.jsonschema.json must NOT be edited.
  • The linter repository should have a readme and linting.
  • The linter should be published as a binary (useful to diagnose bug origins).
  • The linter repository should have a .gitignore (IDE files, binaries, OS files, etc. should not be committed)
  • A tag should never be recreated.
  • use main as the default branch name.

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

The code review will start after the completion of those checkboxes (except for the specific items that the team will help to verify).

The reviews should be addressed as commits (no squash).

If the author of the PR is a member of the golangci-lint team, he should not edit this message.

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

@ldez ldez added feedback required Requires additional feedback and removed declined labels Aug 17, 2024
@ldez ldez changed the title feat(linters): add new linter gobreakselectinfor Add new linter gobreakselectinfor Aug 17, 2024
@bombsimon
Copy link
Member

Seems like your linter reports this even if you use labelled breaks which I think shouldn't be an issue when breaking in a select.

package main

func bad() {
    var ch chan string
OUTER:
    for {
        select {
        case <-ch:
            break OUTER
        }
    }
}
› go run ./cmd/go-break-select-in-for .
/home/simon/.../go-break-select-in-for/example.go:9:4: break statement inside select statement inside for loop
exit status 3

@rnben
Copy link
Author

rnben commented Aug 17, 2024

Yes, you are right. I fixed in v0.0.2

func bad(ch <-chan bool) {
	for {
		select {
		case <-ch:
			break // want "break statement inside select statement inside for loop"
		}
	}
}

func good(ch <-chan bool) {
OUTER:
	for {
		select {
		case <-ch:
			break OUTER
		}
	}
}
› go run ./cmd/go-break-select-in-for .
/Users/ruben/workspaces/linter-demo/example.go:8:4: break statement inside select statement inside for loop
exit status 3

@ldez
Copy link
Member

ldez commented Aug 17, 2024

FYI v0.0.0, v0.0.1, v0.0.x are not valid semver version.

https://semver.org/#how-should-i-deal-with-revisions-in-the-0yz-initial-development-phase

@rnben
Copy link
Author

rnben commented Aug 17, 2024

Should starting at 0.1.0 ?

@rnben
Copy link
Author

rnben commented Aug 19, 2024

Ok, I have updated, new version v0.1.0

@ldez ldez changed the title Add new linter gobreakselectinfor Add gobreakselectinfor linter Aug 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feedback required Requires additional feedback linter: new Support new linter
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants