Support "gopls check" linter

[fho]

Add support for running gopls check via golangci-lint.

gopls check can find issues that cause compilation problems without having to compile the code.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[silverwind]

This would be very useful. Currently I'm running gopls check <files> in addition to golangci-lint and it discovers a number of issues that no existing linter can find like impossible conditions and such.

I have to concur thought that gopls is definitely on the slower side. Takes 3 minutes to lint the gitea codebase.

[silverwind]

@ldez any chance for re-open?

Currently I'm using this script to lint with gopls. Would appreciate having gopls as a full-fledged linter.

[ngotchac]

@ldez Any reason why this go declined?

[ldez]

gopls is a binary not designed to be used as a library: all the analyzers are inside an internal package and those analyzers use internal packages outside of the gopls module (yes it is possible in some cases).
We can easily say that it is an intentional design to strongly limit the usage of those analyzers outside gopls.

So for now, we will not try to overcome those limitations even if I have an idea to "fix" the problem.

rule n°1 of open-source: no is temporary, yes is forever.

[ngotchac]

Gotcha, thanks for the prompt response! Too bad they made it that way..

[silverwind]

all the analyzers are inside an internal package and those analyzers use internal packages outside of the gopls module

Even though the analyzers are in folder called "internal", they can be imported normally and also be ran as a CLI, for example https://pkg.go.dev/golang.org/x/tools/gopls/internal/analysis/modernize.

But I guess gopls makes no stability guarantees regarding these pseudo-public modules. Maybe a issue should be raised so that gopls exposes a proper public API for linters.