x/tools/gopls: provide a way to suppress analysis diagnostics for certain files

[OneOfOne]

gopls version

❯ gopls -v version
Build info
----------
golang.org/x/tools/gopls master
    golang.org/x/tools/gopls@(devel)
    github.com/BurntSushi/toml@v0.4.1 h1:GaI7EiDXDRfa8VshkTj7Fym7ha+y8/XxIgD2okUIjLw=
    github.com/google/go-cmp@v0.5.6 h1:BKbKCqvP6I+rmFHt06ZmyQtvB8xAkWdhFyr0ZUNZcxQ=
    github.com/sergi/go-diff@v1.1.0 h1:we8PVUC3FE2uYfodKH/nBHMSetSfHDR6scGdBi+erh0=
    golang.org/x/mod@v0.5.1 h1:OJxoQ/rynoF0dcCdI7cLPktw/hR2cueqYfjm43oqK38=
    golang.org/x/sync@v0.0.0-20210220032951-036812b2e83c h1:5KslGYwFpkhGh+Q16bwMP3cOontH8FOep7tGV86Y7SQ=
    golang.org/x/sys@v0.0.0-20211019181941-9d821ace8654 h1:id054HUawV2/6IGm2IV8KZQjqtwAOo2CYlOToYqa0d0=
    golang.org/x/text@v0.3.7 h1:olpwvP2KacW1ZWvsR7uQhoyTYvKAupfQrRGBFM352Gk=
    golang.org/x/tools@v0.1.7 => ../
    golang.org/x/xerrors@v0.0.0-20200804184101-5ec99f83aff1 h1:go1bK/D/BFZV2I8cIQd1NKEZ+0owSTG1fDTci4IqFcE=
    honnef.co/go/tools@v0.2.1 h1:/EPr//+UMMXwMTkXvCCoaJDq8cpjMO80Ou+L4PDo2mY=
    mvdan.cc/gofumpt@v0.1.1 h1:bi/1aS/5W00E2ny5q65w9SnKpWEF/UIOqDYBILpo9rA=
    mvdan.cc/xurls/v2@v2.3.0 h1:59Olnbt67UKpxF1EwVBopJvkSUBmgtb468E4GVWIZ1I=

Is there a way to stop the linter for just one function or file?

In some of our tests we're bad bad things intentionally and it just clutters the problems pane.

[findleyr]

No, there isn't a way to do this, currently.

Based on the issue subject, are you asking for something akin to the golangci-lint //nolint directive?

[OneOfOne]

@findleyr correct, i'd even be happy if it worked for a single line instead of a while function, the spam is real and I'd rather not turn off the specific linter for the whole project.

[findleyr]

@OneOfOne would you want this just for lint/analysis errors, or would you want it for all diagnostics (including "compiler" errors). I am sympathetic to wanting to suppress lint errors, but I don't think we should ever suppress errors from the compiler (the parser/type checker). If there is a compiler error many other gopls features (autocompletion, jump to definition, etc.) may not function correctly, and it would be confusing if this happens silently.

[OneOfOne]

Only lint/analysis of course, compiler errors are important.

[robpike]

My two cents:

Compiler errors are important, but linter errors are not. Do not decorate your code with annotations to silence a defective tool. Instead, use better tools and depend on ones that are reliable. It is just bad practice to require your build to pass through a capricious tool like a linter.

If you insist on using a linter, find a way for your local build process to disable it when required. Don't require externally-supported tools to honor your process, and don't require source code add marks to disable one too. That slippery slope leads to a valley of toxic muck.

[timothy-king]

and it just clutters the problems pane.

Can you describe what the problem is in more detail? What I have managed to grasp so far is that gopls is reporting accurately on intentionally buggy code. This does not sound like a problem yet so I think I am missing something. Maybe a brief description of how the workspace is setup? Also what is the test?

[OneOfOne]

@timothy-king @robpike this is about gopls' linter/analysis not the compiler, to be more specific, we have some tests that that trigger string literal contains Unicode format characters, consider using escape sequences instead ST1018 for example, we know it's buggy, but it's intentional to test our codebase.

[robpike]

I understand the problem you've set yourself, I'm just asking that we don't end up with annotated source code as a solution. Instead, for your particular situation, construct a way to avoid failing on the linter error for that broken code. In other words, it's your problem to solve, not the Go team's, in my obviously biased opinion. Gopls should not make bad code easier to work on. That just contradicts its purpose.

[OneOfOne]

I'd argue that you can already do that by turning off the guilty linter rule with gopls options, but instead of turning it off for a specific function or line like I requested, it'd apply to the whole codebase which can lead to actual problems.

…

On Mon, Jan 24, 2022, 2:49 AM Rob Pike ***@***.***> wrote: I understand the problem you've set yourself, I'm just asking that we don't end up with annotated source code as a solution. Instead, for your particular situation, construct a way to avoid failing on the linter error for that broken code. In other words, it's your problem to solve, not the Go team's, in my obviously biased opinion. Gopls should not make bad code easier to work on. That just contradicts its purpose. — Reply to this email directly, view it on GitHub <#50764 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIHY6Z6LOMJGPAI6JMDYKTUXUHATANCNFSM5MSZTM2A> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[findleyr]

@robpike I fully agree about avoiding annotated source code, and independent of the solution I don't think we should couple ourselves to golangci-lint -- that is bound to be problematic.

However, I do think at a high level it is reasonable to request that gopls provide a mechanism to disable analyses for certain files or directories. Per your point:

If you insist on using a linter, find a way for your local build process to disable it when required.

Many users primarily consume static analysis through their editor, where the analog of this advice is to find a way to disable the linter where required in the development process. Right now gopls only provides an on/off switch, and I can understand how in certain codebases, perhaps in the process of incremental cleanup, it could be desirable to disable/enable linters for portions of the codebase.

With all that said, gopls has long avoided any sort of per-directory configuration, and I'd like to keep avoiding it as long as possible, until the benefit is unambiguous.

With respect to this request, it seems possible that no additional gopls configuration is required. The default set of linters gopls uses are the cmd/vet analyzers + a few additional analyzers that we deem to have a very low rate of false positives. However, we allow our users to enable more opinionated linters, included those from staticcheck. ST1018, is a staticcheck style check.

Staticcheck has its own mechanism for per-directory configuration, which we have a long-standing request to support (#36373). I'd rather we do that than build an analogous mechanism for gopls.