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.

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

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?

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

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.

#36373 (comment)

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

@adityaU yep, the field was changed a little:

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

@OneOfOne Thank you so much. :)

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?

"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

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

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

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.

@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.

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.

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.