gopls: support a setting to control the frequency of diagnostics

[stamblerre]

It's possible that some users might like to see diagnostics only when they save a file, rather than seeing them as they type. It is also possible that some users may want to use gopls without seeing any diagnostics at all.

Depending on the popularity of these use cases, we should consider supporting these two configurations.

Please react with a 🚀 if you would like to see diagnostics only when you save a file, not as you type. Please react with a ❤️ if you would like to disable diagnostics from gopls completely.

Original discussion on https://github.com/microsoft/vscode-go/issues/2907.

[gopherbot]

Change https://golang.org/cl/280601 mentions this issue: src/goLanguageServer: remove languageServerExperimentalFeatures

[tamayika]

Is there any way to use custom go vet tool with gopls enabled in >= 0.21? Or is there any way to embed custom analysis to gopls?

Here is my configuration.

{
  "go.vetFlags": [
    "--vettool=${workspaceRoot}/bin/my-vet-tool"
  ],
  "go.languageServerExperimentalFeatures": {
    "diagnostics": false, // deprecated and not work >= 0.21
  },
}

Current workaround is to rollback vscode-go to 0.20.x.

[hyangah]

@tamayika Thanks for the report. Sorry that I didn't know users depend on this feature to use custom vet analysis. Currently gopls doesn't allow custom analysis. @stamblerre This affects the current language server users. I will prepare a partial rollback of cl/280601 that still leaves the diagnostics flag.

Turning completely off gopls's diagnostics because of the lack of custom analyzer support in gopls isn't ideal. I think we need a way to allow vet/buildOnSave when the language server is running (so filed #1109 for investigation).

Out of curiosity: @tamayika is there a reason that your analyzer can't run as a linter?

[tamayika]

Thanks for the support.

go.lintTool is already used by other lint tool(revive) in my configuration. So if go.lintTool supports multiple linters and go vet command with custom vet tool, it may solve the problem.

[gopherbot]

Change https://golang.org/cl/285253 mentions this issue: src/goLanguageServer: partial revert of cl/280601

[gopherbot]

Change https://golang.org/cl/285256 mentions this issue: [release] src/goLanguageServer: partial revert of cl/280601

[hyangah]

@tamayika thanks for understanding. Released v0.21.1 and that will still accept the flag. We hope to address your use case in #1109, separate from this issue.

[tamayika]

Thanks for the release. I confirmed it works now with my configuration.

[mrjrieke]

So, it is an improvement on startup. At least I can load the main root source code page of my project. But the minute I start typing (and saving) code changes, gopls takes off and consumes 290% and 6.5g of ram. I'm turning language server off again locally in vscode.

[stamblerre]

@mrjrieke: I notice you've commented similar things on a few other issues, but this issue is about the diagnostics UI, not CPU or memory usage. I have marked your comment as off-topic. If you would like us to investigate a problem, please read the troubleshooting guide and file your own separate issue.

[mrjrieke]

@stamblerre, yes, this is the wrong bug to issue on. The link from vscode about language server being on by default somehow led me here. It is/was an existing issue, and I thought I was adding to that. Sorry for the confusion.

[hyangah]

Discussion around textDocument/getDiagnostics looks relevant. The proposed API for pullDiagnostics is currently available in vscode language client

[alok87]

What is required to use this?

[alok87]

Upgrading to the latest gopls version fixed it for me go install golang.org/x/tools/gopls@latest

[hyangah]

@alok87 what problem were you trying to solve? This issue was about whether to allow users to control "when" gopls runs diagnostics (realtime vs on-save vs never).

While we are here, are we still interested in this feature? Is it still a prerequisite before we remove languageServerExperimentalFeatures setting?

[alok87]

My vs code was crashing, auto go imports and everything stopped working. Vs code showed a link to this issue, i did not read much what was going on here, tried updating vs code go to latest and things started working

[alok87]

The issue was something different, please ignore my messages.

[belak]

I ran across this in our Go setup doc a while back...

  "go.languageServerExperimentalFeatures": {
    // Disable diagnostics, because they'll run on the entire repo. With them
    // disabled, go vet will run on just the package.
    "diagnostics": false
  },

I assume if that comment is true that there will be a huge difference in performance with monorepos.

[hyangah]

@belak For mono-repo, build.directoryFIlters can be used to make gopls scale. (not only diagnostics, but more), and if the mono-repo consists of multiple go modules, gopls won't diagnose modules in subdirectory unless users explicitly add them in go.work file or enables the experimental workspace module mode.

[gopherbot]

Change https://go.dev/cl/501199 mentions this issue: package.json: remove go.languageServerExperimentalFeatures setting

[yayiji]

Why did you remove this setting? Are there any other options I can use to disable the diagnostics?

[hyangah]

@yayiji Can you tell us more why you want to disable gopls's diagnostics? (which includes go build, vet error reporting)

Over the three years, we left this issue open to hear from users. We heard two reasons that made some users disable the default gopls diagnostics and we believe they are no longer a big issue.

• Performance - over the last years, gopls performance/stability improved significantly. The latest gopls v0.12.x enables incremental build/diagnostics which I hope allows more scalable analysis as you type, etc, even when you work on a huge repos. There is also a directoryFilters option users narrow their working directories when working on a mono repo. If you turned off gopls diagnostics due to the performance concer, give it another try and report an issue if it doesn't meet your need.

• Customization - some users wanted to run a custom linter through 'vet'. In https://github.com/golang/vscode-go/issues/1109#issuecomment-1015542490 we discussed alternatives.

If there are other issues you wanted to work around by disabling gopls's diagnostics, please let us know.

[yayiji]

Hi @hyangah, I actually do diagnostics, but only when I need to.

When I am coding, I really want everything to be quiet so I can focus on coding and not have anything distracting me.

After that, if I need to check my code, I will run go lint or go vet for diagnostics.

[hyangah]

@yayiji Do you manually run go vet and go build from terminal? We can have an option to turn off (or hide) all diagnostics. That will include compiler errors, too. Will this work for you?

[yayiji]

@hyangah I use go vet or go lint in vscode from the command palette. Other commands I prefer to use from the terminal.

I have the following configuration in my setting.json

  "go.lintOnSave" :"off",
  "go.vetOnSave":"off",
  "go.languageServerExperimentalFeatures": {
      "diagnostics": false
  },

The last setting worked perfectly before, but now it does not work.

[evan361425]

Seams like it is default setting on vet(only diagnostic when save the file).

vet the current package on file saving

But it still diagnose my code every time I type and I try to add some flags on gopls server:

// vscode settings.json
{
  "gopls": {
    // (Advanced) diagnosticsDelay controls the amount of time that gopls waits
    // after the most recent file modification before computing deep diagnostics.
    // Simple diagnostics (parsing and type-checking) are always run immediately
    // on recently modified packages.
    // This option must be set to a valid duration string, for example "250ms".
    "ui.diagnostic.diagnosticsDelay": "10s"
  }
}

Not what I want that should diagnostics only after I save the file, but still some work around?

[metaleap]

There's a lot of talk about custom vet etc. in this thread but I got here because the original "some users might like to see diagnostics only when they save a file" — which I'm really keen on! And not just me, there's literally-dozens-of-us!

Seeing all sorts of live wiggly red lines bouncing about while typing the yet-incomplete line or block irritates me to no end. (In fact, if one could just tell VS another color than red/orange/anything-bright, it would also solve my hangup just as well.)

Having seen the mentions here of go.languageServerExperimentalFeatures I tried it out with "go.languageServerExperimentalFeatures": {"diagnostics": false} and it works a charm! Soon as I save, the diagnostics and wigglies do show up, which I then appreciate, having completed my current train of thought into code.

Now I notice that this very option is already depreciated and primed for removal.

Please leave it in and just rename the "experimental" naming! What's the hurt? It already "works" as far as the original comment goes. Some users do really treasure show-probs-on-save-only. Not constant "realtime nagging", because one just typed a var and haven't used it yet, or just typed a func body and isn't returning yet, etc etc...

[metaleap]

Just realized a subtlety with this, as it is it doesn't truly solve "diags-on-save-only" — when a change is fine for the .go file being saved but breaking other ones in other pkgs. Live diags show this, and so would diags-on-save ideally. But not currently with "diagnostics":false. So back to live diags for me for now I guess...

[gopherbot]

Change https://go.dev/cl/534861 mentions this issue: gopls/internal/lsp: add OnSave diagnostics

[hyangah]

I just merged cl/534861 that implements aka "surface problems on file save only" feature. The change adds a new setting ui.diagnostic.diagnosticsTrigger. To test this feature:

1. Build gopls from the source.

   git clone https://go.googlesource.com/tools
   cd tools/gopls
   go install

2. Use this setting: diagnosticsTrigger

    "gopls": {
        "ui.diagnostic.diagnosticsTrigger": "Save", 
     },

3. Restart gopls.

Please test it and provide feedback. I hope we can get this included in gopls v0.15.

[metaleap]

@hyangah wowzers, works flawlessly! I'm so looking forward to this being merged into mainline gopls asap :+1: tranquil typing of code without the overhasty red lines, I'll take it!