Support custom analyses as a go.lintTool

[leighmcculloch]

Is your feature request related to a problem? Please describe.

The analysis, singlechecker, and multichecker packages support building custom analysis tools, but the vscode-go extension does not support them. Currently when attempt to use a custom tool, the following warning is displayed:

The tool does get executed, but any problems identified by it are not captured by the vscode-go extension.

Developers have the tools to build their own linting tools with analysis and singlechecker, and their own lint aggregators using multichecker, but cannot use those tools in vscode-go without getting their linting tools included in other tools like golangci-lint.

The analysis package says the following in its docs:

Package analysis defines the interface between a modular static analysis and an analysis driver program.

The multichecker package says the following in its docs:

This package makes it easy for anyone to build an analysis tool containing just the analyzers they need.

It'd be useful to carry on these principles and goals ☝🏻 into the IDE.

Describe the solution you'd like

I'd like to be able to use any singlechecker / multichecker based analysis tool as the go.lintTool with the vscode-go extension, so that custom lint tools can be used directly with VSCode, instead of having to depend on tools like golangci-lint incorporating the analysis tools.

{
    // ...
    "go.lintTool": "mycustommultichecker",
    // ...

Describe alternatives you've considered

The alternative is to continue to rely on tools like golangci-lint to incorporate analyses so as to get support for them in vscode-go.

Another alternative might be to add support for custom analyses to gopls, although the impression I got on Gophers Slack (discussion) is that gopls doesn't call out to external tools at all.

Additional context

Gopls also supports analyses directly, but only those compiled directly into gopls, and not external programs, so I suspect the right place to open this issue is here on the vscode-go extension. However, I've also seen the following issue that suggests maybe linting is moving to gopls, so it isn't completely clear to me where this issue should target:

• gopls: recommend that users enable staticcheck via gopls instead of through the lintTool #1295

[findleyr]

Hi, thanks for the thoughful request.

I think we'd rather pursue turning gopls itself into an extensible analysis driver (or have gopls control a sidecar): golag/go#59869

This will allow gopls' built-in analysis to share work with the additional analyzers.

[leighmcculloch]

I think we'd rather pursue turning gopls itself into an extensible analysis driver

That would be preferred in my opinion as well.

I'm closing this issue in favor of:

• x/tools/gopls: move analyzers to an extensible sidecar go#59869