x/tools/gopls: respect staticcheck config file

[llimllib]

What version of Go are you using (go version)?

$ go version
go version go1.13 darwin/amd64

Does this issue reproduce with the latest release?

govim is using commit f13409bb, which is pretty new, and it reproduces

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN="/Users/llimllib/go/bin"
GOCACHE="/Users/llimllib/Library/Caches/go-build"
GOENV="/Users/llimllib/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/llimllib/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.13/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.13/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/llimllib/code/tools-golang/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/r4/mc760j7j6xjdgr5p5hxk_xrw0000gq/T/go-build877572449=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

I don't know how to use gopls directly, so here's how to reproduce through govim

1. Create a directory
2. Create a staticcheck.conf file with these contents:

checks = ["all", "-ST1005"]

3. Create a main.go file:

package main

import "fmt"

func main() error {
	return fmt.Errorf("This capitalized error should be ignored but isn't")
}

4. Note that running staticcheck . or staticcheck main.go do not raise any errors
5. Turn on vim, with govim installed and staticcheck enabled via call govim#config#Set("Staticcheck", 1)
6. Note that govim flags error ST1005 on line 6

Reading the gopls logs from govim shows:

[Trace - 10:10:46.572 AM] Received notification 'textDocument/publishDiagnostics'.
Params: {"uri":"file:///private/tmp/govim-bug/main.go","version":1,"diagnostics":[{"range":{"start":{"line":5,"character":18},"end":{"line":5,"character":18}},"severity":2,"source":"ST1005","message":"error strings should not be capitalized","tags":[1]}]}

As you can see from the config, ST1005 ought to be ignored for this file.

(I feel pretty certain that govim isn't doing anything wrong in how it launches or communicates with gopls? But if I've got this error filed on the wrong side of that divide, I apologize)

What did you expect to see?

No ST1005 errors flagged on main.go

What did you see instead?

An ST1005 error flagged on main.go

[gopherbot]

Thank you for filing a gopls issue! Please take a look at the Troubleshooting guide, and make sure that you have provided all of the relevant information here.

[OneOfOne]

Not sure if vim supports json config for gopls, however the way to do this in vscode is:

	"gopls": {
		"experimentalDisabledAnalyses": ["ST1000", "ST1003"],
		"staticcheck": true
	}

Which is based on https://github.com/golang/tools/blob/master/gopls/doc/settings.md

[llimllib]

I read that page but missed that flag! I will look into setting that flag in govim.

It seems to me that the issue is still worthwhile because not checking the config file seems a surprising behavior?

[OneOfOne]

It might be because gopls imports staticcheck directly rather than invoking the external binary, but not 100% sure.

[ianthehat]

Yes, gopls uses the static check analyzeers directly, and does not have or support all the features of the staticcheck binary. It runs the checkers in a very different way and will probably never fully overlap. There are some things in the config that it might be reasonable to converge, but it needs to be done in a way that works for non staticcheck analyzers too, so it needs some thought.

[adityaU]

#36373 (comment)

this is not working anymore. Are there still ways to disable individual checks of staticcheck ?

[OneOfOne]

@adityaU yep, the field was changed a little:

"gopls": {
		"staticcheck": true,
		"analyses": {
			"ST1000": false,
			"ST1003": false
		}
// other options
	}

[adityaU]

@OneOfOne Thank you so much. :)

[sam-github]

It also doesn't appear to respect line based directives, like https://staticcheck.io/docs/#line-based-linter-directives, or does it have a different syntax for that?

[GAZ082]

"gopls": {
		"staticcheck": true,
		"analyses": {
			"ST1000": false,
			"ST1003": false
		}
// other options
	}

Looks like this is not working anymore?

Version: 1.61.2
Commit: 6cba118ac49a1b88332f312a8f67186f7f3c1643
Date: 2021-10-19T14:58:13.605Z
Electron: 13.5.1
Chrome: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Linux x64 5.12.18-1-ck-nehalem

[findleyr]

@GAZ082 sorry for the slow response, but disabling individual analyses should definitely still work.

[findleyr]

Looking into this now, it seems like we should actually already be loading the config file via the config.Analyzer, which is required by analyzers that use configuration, but that is failing somehow...

Or maybe it isn't. Warrants investigation.

If it does work, we could theoretically inject our view of the filesystem (including overlays) into config.Analyzer.Run, but something tells me that's a bad idea -- we can check with dominikh once we understand the current status better.

CC @dle8

[dominikh]

In Staticcheck, there are two parts to configuration. Configuration that gets used by individual analyzes via config.Analyzer, and configuration that controls the staticcheck command as a whole. The former should just work in gopls. The latter requires explicit support by the analysis runner. Importantly, the checks option is handled by the analysis runner, not by the individual analyzes.

[findleyr]

@dominikh is the checks option the only gap in configuration? In that case, assuming the integration via config.Analyzer works, it may not be worth changing the current behavior. For example, it looks like the current staticcheck API for using the config is via Runner.Run, which we wouldn't be able to use*. If my understanding is correct, then in order to fully honor the staticcheck config we'd have to interpret it ourselves, which I'd prefer not to do.

*truth be told, I'm not actually sure whether it's a bad idea to use Runner.Run, given that it has its own caching, does full analysis of the package graph, and holding onto the staticcheck IR doubles our memory footprint... but that is a separate discussion.

[dominikh]

is the checks option the only gap in configuration?

It currently is, yes.

If my understanding is correct, then in order to fully honor the staticcheck config we'd have to interpret it ourselves, which I'd prefer not to do.

That is my understanding, too.

I'm not actually sure whether it's a bad idea to use Runner.Run

It would seem weird to use two different analysis runners IMO. Also, Runner manages its own concurrency and is designed for throughput. I'm not sure how well that would fit into gopls.

[findleyr]

is the checks option the only gap in configuration?

It currently is, yes.

Thanks. In that case, I think we should not do anything here other than verify that config.Analyzer is WAI.

[zerocorebeta]

In vscode, gostaticcheck is respecting config file named "staticcheck.conf" but zed https://zed.dev/ which is using gopls_0.16.2

Can someone please guide me how vscode can respect this config file but not zed editor? any setting that i am missing?

I am using this as workaround for now.

"lsp": { "gopls": { "gofumpt": true, "initialization_options": { "directoryFilters": ["-**/node_modules", "-**/.git"], "symbolScope": "workspace", "staticcheck": true, "templateExtensions": ["tmpl"], "analyses": { "ST1017": false, "nilness": true, "unusedparams": true, "unusedvariable": true, "unusedwrite": true, "useany": true }, "codelenses": { "gc_details": true } } } },

note: ST1017 which is part of my config file which i require skipping.

[hyangah]

@zerocorebeta VS Code Go plugin does not use gopls' staticcheck integration by default, but calls the staticcheck command line tool. I guess that is why.