Add "nilaway" as a linter

[Dentrax]

Your feature request related to a problem? Please describe.

NilAway is a static analysis tool that seeks to help developers avoid nil panics in production by catching them at compile time rather than runtime.

Describe the solution you'd like.

https://github.com/uber-go/nilaway

Describe alternatives you've considered.

-

Additional context.

IIUC, nilaway is more like a "tool" rather than a linter.

/cc @yuxincs @zzqatuber

[ldez]

Analyzers that just display potential problems are not considered as linters inside golangci-lint because of the large number of false positives.
Those kinds of analyzers are not allowed.

Similar to #3969

[Dentrax]

Ah, good to know. Maybe devs of that tool can optimize the code base to provide a linter interface.

Just curious to ask, why don't you provide a some kind of feature gate to allow "tools" and "false positives"? I totally understand your "golangci-lint's criteria". But maybe you can define "linter graduation policy": alpha > beta > stable, etc. So enabling experimental gates could allow non-stable and false-positive tools/linters.

I know, this would be a part of totally different proposal to discuss more about.

[ldez]

Maybe devs of that tool can optimize the code base to provide a linter interface.

This is not the problem: the problem is false positives, not the linter interface.

Just curious to ask, why don't you provide a some kind of feature gate to allow "tools" and "false positives"? I totally understand your "golangci-lint's criteria". But maybe you can define "linter graduation policy": alpha > beta > stable, etc. So enabling experimental gates could allow non-stable and false-positive tools/linters.

The goal of golangci-lint is to be accurate and relevant, i.e. no false positives, this is why we have default exclusions.
False positives are no relation with a linter "state" (alpha > beta > stable or experimental).
So, for now, there is no possibility of "false-positive linter" or "potential issues detector".

[karelbilek]

I don't fully understand this policy, when golangci-lint has style linters which are all very "potential issue detectors" and have lot of "false positives", but, it's up to you I guess

[YishaiBerg]

Why not just mention the problems in the documentation and allow devs the choice of whether to use it or not? Why opinionated over flexible?