Show all errors and warnings in project for all Go files, not just opened ones

[niebloomj]

We do see all errors and warnings in the "problems" tab when we open a Go file with errors, but they are removed from the problems tab when we close the file. It would be great to be able to see all the problems of all the files in a project.

This was requested to be globally implemented in the vscode issue at microsoft/vscode#13953 but we were told that this is not something to be implemented globally, but per language/plugin.

I do understand not everyone would like to have this feature, or that it would be useful just for some cases or projects., specially because it would consume too many resources. A way to turn this feature on/off per project would help the user when to turn it on/off.

[hyangah]

@niebloomj Can you please share a concrete example to demonstrate it? (repro case is welcome)

With gopls, my understanding is that errors in all recognized files and packages in workspace are presented regardless whether the file is open or not, but diagnostics for files in single-file mode or vendor directory show up only when the file is open. But maybe this is not true.

If you are talking about errors detected by a linter (staticcheck, golang-ci-lint, ..), doesn't "go.lintOnSave": "workspace" setting do what you want?

[DylanSpOddball]

@hyangah I've run into the same issue as the OP. Repro:

main.go:

package main

import "fmt"

func main() {
	i := 3
	i = i
	fmt.Println(i)
}

The self-assignment i = i triggers a warning from the assign analyzer.

With main.go open, VSCode reports the problem:

But with the file closed, the problem isn't reported:

gopls doesn't appear to have a command-line flag for running all analyses, so it's not possible to use that as a linter, or even run its analyses manually.

[hyangah]

@DylanSpOddball can you create go.mod to define the boundary of the Go project (main module) and reopen it?

[DylanSpOddball]

Added the following go.mod:

module vscode-repro

go 1.17

Same issue persists after reopening.

[hyangah]

@DylanSpOddball Thanks, you're right. Indeed the compiler errors and go.mod diagnostics (error) persist, but lint/vet errors (warning) disappear once the file closes.

[Trace - 17:09:30.910 PM] Sending notification 'textDocument/didOpen'.
Params: {"textDocument":{"uri":"file:///Users/hakim/ww/main.go","languageId":"go","version":322,"text":"package main\n\nimport (\n\t\"fmt\"\n)\n\nfunc main() {\n\ti := 1\n\ti = i\n\tfmt.Println(\"\\n\")\n}\n"}}


...


[Trace - 17:09:30.918 PM] Received notification 'textDocument/publishDiagnostics'.
Params: {"uri":"file:///Users/hakim/ww/main.go","version":322,"diagnostics":[{"range":{"start":{"line":8,"character":1},"end":{"line":8,"character":1}},"severity":2,"source":"assign","message":"self-assignment of i to i","tags":[1]},{"range":{"start":{"line":9,"character":1},"end":{"line":9,"character":18}},"severity":2,"source":"printf","message":"fmt.Println arg list ends with redundant newline"}]}

...


[Trace - 17:09:36.648 PM] Sending notification 'textDocument/didClose'.
Params: {"textDocument":{"uri":"file:///Users/hakim/ww/main.go"}}


[Trace - 17:09:36.914 PM] Received notification 'textDocument/publishDiagnostics'.
Params: {"uri":"file:///Users/hakim/ww/main.go","diagnostics":[]}

I can imagine running all the analysis all the time for all files can be expensive, but we may investigate how to enable this for users who explicitly opt in (either by setting change or by command like gc_details). cc @findleyr @pjweinb @suzmue

BTW, I realized the "Go: Lint Workspace" command is broken due to this behavior.

A workaround (which isn't great and I don't recommend) is to disable gopls diagnostics and manually trigger Vet and Lint by either running "Go: Vet Workspace" and "Go: Lint Workspace" or saving files.

{
    "go.languageServerExperimentalFeatures": {
        "diagnostics": false
    }
}

[MarkCaro]

Hoping to have this feature soon as well, since I always aim to have zero Errors and Warnings in all my projects and having to open each file to resolve them all would be too cumbersome.

I agree that having a Setting that can be set to either On or Off would be best since this behavior might not be advisable for extremely large projects.