Golang x/tools/gopls: Diagnostics: suppress diagnostics from dependencies (incl. std)

Is your feature request related to a problem? Please describe.

In the PROBLEM tab of my VS Code, I always see a lot of errors from Go standard lib and some 3rd party libs, e.g.:

But I do not care about those errors at all, I only want to see the errors of my own project code.

Describe the solution you'd like

Provide a configuration parameter to report errors only from the project's own code.

Comment From: firelizzard18

I believe this is a gopls request, @adonovan? I have noticed something similar - depending on the project if I use Ctrl+P (Go to File) and type value.go, the first result will be from the stdlib reflect package instead of my own code, which is pretty much never what I want.

Comment From: h9jiang

You are right, this is part of the gopls.

Let me transfer the issue to gopls. I have seen something maybe consider "weird" in one of the previous issue, golang/go#73781, when try find references, if you open dependency module, gopls will return references from that opened file as well. if you close that file and call find references, the references in that file will disappear from your find references.

I did a local experiment, if you open base64.go from encoding standard library, the problems will be reported. If you keep it open and look at some other file, the problem does not go away. (the file is still consider opened but not in the top most tab). If you close it, it will disappear.

I will leave Alan for a better and precise answer.

Comment From: qianzhangxa

It's a very small Go project I'm working on, but there are 600+ errors, and none of them are from my own code, this is crazy. I think it was just because I opened /usr/local/go/src/runtime/panic.go, once I closed this file, all these errors went away.

Comment From: findleyr

We should either fix these lint errors in the standard library, or fix the analyzers to not detect them.

(either they are false positives, or true positives!)

Comment From: adonovan

Many of them are false positives: unusedfunc gets very confused by the idiosyncrasies of the runtime package, such as compiler intrinsics, functions called only by handwritten assembly, and functions used only in some build configurations.

Ideally, we would annotate intrinsics somehow, or enumerate them in a var ( _ = runtime.writeBarrier; ... ) declaration, to avoid false reports and statically check that they are indeed referenced by the compiler.

When support Go assembly files is done, we could make its infrastructure available as a helper analyzer so that unusedfunc could take advantage of it.

Until then, we should suppress unusedfunc on all packages that are dependencies of runtime.