x/tools/gopls: improve handling for build tags

[stamblerre]

We need to handle build tags correctly in the LSP. If a user is on Linux, they should still see completions, diagnostics, etc. for files tagged with any other OS.

[glerchundi]

Bitten by this also, lost an hour trying to figure out why after migrating to gopls basic functionalities didn't work...no import-organize, no format, no nothing. Afterwards I found that it's was working properly for everything except for files with build tags as mentioned in #31286.

[myitcv]

I'm wondering whether this is the right issue to become the umbrella issue for our long-running discussion about context?

[sjdweb]

This is killing me with integration tests that have build tags. Any workarounds known?

[christiankiely]

@sjdweb current workaround I'm using is to set the GOFLAGS environment variable. This is the configuration I'm using in VS Code:

"gopls.env": {
        "GOFLAGS": "-tags=test"
    },

[myitcv]

This was brought up on Tuesday's golang-tools call.

@christiankiely - the "editor level" GOFLAGS approach your describe works in some cases, but not all. Because setting the flag in that way sets the flag for all modules and packages, i.e. for the gopls instance used by the editor.

In discussions we've had thus far it seems for a complete solution we need to be able to define the sets of valid build flags at various levels:

• Editor level (i.e. throughout editor)
• Module level
• Package (tree) level
• File level

We also need:

• the ability to specify, from within the editor, which build flags are in operation, because for a given file/package/module there might be multiple valid options
• the ability to then pass this choice on a per request basis to gopls

The conclusion on Tuesday's call was broadly that there are other higher priority issues right now; add to that, a solution that doesn't involve LSP spec changes isn't exactly jumping out at us.

cc @ianthehat @dominikh