Golangci-lint: Support revive

[jirfag]

https://github.com/mgechev/revive

[jirfag]

I've tested revive a bit, looks like all warnings are the same as in golint. Why do we need revive in golangci-lint if we already have golint?

[s3rj1k]

Revive provides more rules compared to golint.

[jirfag]

ok, I will look at it, maybe it's rules are already implemented by other linters

[AlekSi]

In my project I would really like to use this check: https://github.com/mgechev/revive/blob/master/RULES_DESCRIPTIONS.md#empty-lines I don't think it is implemented anywhere else.

[jirfag]

@AlekSi thank you. A similar check is in gofumpt, which is not included into golangci-lint too

[akyoto]

According to their README, revive is 2x faster running the same rules as golint.
So it could replace golint for a performance improvement?

I've used revive as a default linter so far without any problems.

[jirfag]

As I understand It's faster just because of parallel execution. golangci-lint does the same parallel execution between linters (not inside golint only - but if anyone wants to run only golint in golangci-lint he can use revive/golint instead)

[johnrichardrinehart]

Will a PR be accepted which integrates revive into golangci?

[jirfag]

@johnrichardrinehart yep, it will be accepted

[Dentrax]

@jirfag any updates? :)

[jirfag]

@Dentrax contributions are welcome. But, I hope revive uses go/analysis: we would like to include only go/analysis-based linters.

[johnrichardrinehart]

@jirfag You mean this?

It seems that it's not based on x/analysis....

➜  ~ GO111MODULE=on go get github.com/mgechev/revive@3119f5881c5dd864f346426752eb745d3eddb17d
go: downloading github.com/mgechev/revive v1.0.3-0.20200517021941-3119f5881c5d
go: github.com/mgechev/revive 3119f5881c5dd864f346426752eb745d3eddb17d => v1.0.3-0.20200517021941-3119f5881c5d
go: downloading github.com/mgechev/dots v0.0.0-20190921121421-c36f7dcfbb81
go: downloading github.com/fatih/color v1.9.0
go: downloading golang.org/x/tools v0.0.0-20200515220128-d3bf790afa53
go: downloading github.com/olekukonko/tablewriter v0.0.4
go: downloading github.com/fatih/structtag v1.2.0
go: downloading github.com/mattn/go-isatty v0.0.11
go: downloading github.com/mattn/go-runewidth v0.0.7
go: downloading golang.org/x/sys v0.0.0-20191026070338-33540a1f6037

➜  ~ GO111MODULE=on go get github.com/mgechev/revive@master
go: github.com/mgechev/revive master => v1.0.3-0.20200517021941-3119f5881c5d

➜  ~ cd ~/go/pkg/mod/github.com/mgechev/[email protected]

➜  [email protected] go list -f '{{.Deps}}' ./... | grep analysis
➜  [email protected]

I.e. no import "golang.org/x/tools/go/analysis" exists in any source file of github.com/mgechev/revive.

I know it's been some time, but coincidentally I have more time to pursue this, now. Please advise as to whether a PR would be considered in light of this new information.

[gonzaloserrano]

I think this is relevant to the discussion: "x/lint: freeze and deprecate" - https://github.com/golang/go/issues/38968

[johnrichardrinehart]

@gonzaloserrano Thanks for referencing this.

@jirfag In light of the planned deprecation of x/lint, will you consider PRs for non-x/lint linters?

[wburningham]

Ignoring the speed differences, the biggest reason I use revive over golint is the support for "disabling a specific rule or the entire linter for a file or a range of lines". I currently have to run revive and golangci-lint (with golint disabled). Please add support for revive so I can just run one lint command.

[s3rj1k]

@wburningham And actually still feels that revive catches more errors than some of the similar linters in golangci-lint.

It was the case in 2018, now is probably difference of catching errors is lesser.

This all comes from my experience only :)