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

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.

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

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.

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

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

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

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

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

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.

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

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

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

@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 check: allow use of custom vet when using the language server #1109 (comment) we discussed alternatives.

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

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.

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

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

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?

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

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

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

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.

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