Add WSL linter

[bombsimon]

Added linter WSL. Tests and linter is working with golangci-lint run, however I'm experiencing an old issue noted in #255.

This is with golangci-lint built from this commit (master + 08de1f8) and goimports installed with go get today (GO111MODULE=off go get -u golang.org/x/tools/cmd/goimports). No difference with -local flag or not.

golangci-lint run pkg/golinters/wsl.go
pkg/golinters/wsl.go:6: File is not `goimports`-ed (goimports)
        "github.com/bombsimon/wsl"

goimports -w pkg/golinters/wsl.go
gofmt -w -s pkg/golinters/wsl.go

diff \
  <(goimports pkg/golinters/wsl.go) \
  <(cat pkg/golinters/wsl.go) | wc -l
       0

golangci-lint run pkg/golinters/wsl.go
pkg/golinters/wsl.go:6: File is not `goimports`-ed (goimports)
        "github.com/bombsimon/wsl"

[CLAassistant]

All committers have signed the CLA.

[tpounds]

@bombsimon Thanks for the submission. How does your WSL linter differ from https://github.com/ultraware/whitespace which was recently added?

[bombsimon]

@tpounds WSL has a bunch more features other than checking leading and trailing whitespaces in blocks. It checks for variable usages and different node types to determine if there should be a newline or not. Please give the WSL readme a quick look to get a better understanding of how WSL works, there should be a lot of examples describing how the linter works.

EDIT: You could say that the main purpose of WSL is to add whitespaces to not make the code too tight whereas whitespace encourage you to remove whitespaces (altough WSL does both).

[bombsimon]

Other than the goimports issue I see I have a problem with go mod and go1.13. Since I've had some problems with go mod I've set GOSUMDB=off in my go environment and thus didn't notice the issue with my package.

I can't believe I'm having such ha hard time getting go mod to work, I feel stupid.

I've added a tag v1.0.0 to master and I've created a release named v1.0.0. Apparently this is not enough and result in go mod not working:

go: github.com/bombsimon/[email protected]: unexpected status (https://proxy.golang.org/github.com/bombsimon/wsl/@v/v1.0.0.info): 410 Gone

Doesn't seem to ba any problem when trying said URL manually:

http https://proxy.golang.org/github.com/bombsimon/wsl/@v/v1.0.0.info
HTTP/1.1 200 OK
Accept-Ranges: bytes
Age: 64
Alt-Svc: quic=":443"; ma=2592000; v="46,43",h3-Q048=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000
Cache-Control: public, max-age=10800
Content-Length: 50
Content-Type: application/json
Date: Wed, 02 Oct 2019 14:50:55 GMT
Expires: Wed, 02 Oct 2019 17:50:55 GMT
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Xss-Protection: 0

{
    "Time": "2019-10-02T13:06:13Z",
    "Version": "v1.0.0"
}

GOPROXY and GOSUMDB are set to "" in the Travis CI environment and if I do the same in a new project and run go get -u github.com/bombsimon/[email protected] everything is working.

Any help or pointers in the right direction is much appreciated!

[jirfag]

1. please, don't use negative naming
2. please, don't add such duplicating option: any linter can be disabled for tests by exclude-rules. It's not performance effective, I agree, but it should be done in a general way for all linters, not per-linter

[bombsimon]

Sorry about that, I'll remove this since the configuration isn't needed!

[bombsimon]

Ok so now the Travis pipeline fails with the lint error File is not goimports-ed (from goimports). I have no idea how I should solve that, see my previous comments about what I've tried with goimports [-local] and gofmt -s. Any ideas how I could resolve this?

[jirfag]

@bombsimon did you update your goimports?
also, you can fix it by committing suggestion by golangcibot or by running golangci-lint run --fix

[bombsimon]

@jirfag Just fixed them with golangci-lint instead of goimports itself. Don't know why goimports -w doesn't fix the issue but I guess I'm running a bad version. goimports -w doesn't make any changes before or after the fix with golangci-lint.

Seems like GolangCI is happy now at least! :)

[tpounds]

@bombsimon Can you add some tests that verify the linter's behavior? This will ensure any regressions will be caught when we upgrade linter versions, add/remove configuration options, and/or tweak internal.

e.g.

https://github.com/golangci/golangci-lint/blob/master/test/testdata/dogsled.go
https://github.com/golangci/golangci-lint/blob/master/test/testdata/errcheck.go
https://github.com/golangci/golangci-lint/blob/master/test/testdata/gocognit.go

Edit: Looks like I missed that you added a single test. What do you think about expanding that to more of the checks?

[bombsimon]

@tpounds Absolutely, will add more tests!

[tpounds]

@bombsimon Thanks for the additional tests! It looks like CI is still failing due to a go.mod/go.sum mismatch.

https://travis-ci.com/golangci/golangci-lint/jobs/242161917#L699

Can you run go mod tidy and/or make vendor to fix this issue?

[tpounds]

@bombsimon Nice! Thanks for the contribution! 🚢

[bombsimon]

@tpounds Thank you for your feedback, help and the merge! What's common practice regarding changes (new errors, new/changed line markings etc)? Should I bump major or minor if/when I do changes to those? It's not really a common interface/API used by other's so I might as well ask. Anything else I should think about now that it's a part of golangci-lint?

[tpounds]

@bombsimon In general I think following standard semantic versioning is reasonable. In the case of third party linters it's fairly inconsistent across the board. That said, I think these are general interpretations to the semver guidlines that seem reasonable to me:

1. Bump major version when you add a new detection rule that is on by default or flip an existing detection rule from on to off or off to on.
2. Bump minor version when you add a new detection rule that is off by default but can be opted into.
3. Bump patch version when you fix a detection bug (e.g. fix false positives/negatives), update deps, etc.

/cc @jirfag