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

[breml]

Bitten by this as well. I use build tags to distinguish between normal builds and debug builds. Now VSCode reports logError redeclared in this block error and the file is constantly marked as having errors.

[gracenoah]

Another populate use case: when using wire, there are two copies of the initializers:

1. The template in a file with a build tag that never gets compiled
2. The real one generated by wire with no build tags

gopls highlights them as duplicate definitions because it ignores build tags.

Is there a short term workaround in this simpler use case? Some way to make gopls ignore files with the wireinject build tag?

[stamblerre]

Thank you for sharing this info. We realize that this is an issue that affects a lot of people, so we're trying to come up with a viable solution. It's a complicated problem, but to start, I think we can try to disable diagnostics on files that would be excluded given your GOOS/GOARCH.

[evanphx]

As a data point, I'm experiencing this today in any package that picks up os/user because it uses build tags to decide how to wire in OS user lookup. In my case, it's that analysis fails because cgoLookupHost isn't defined as files aren't being evaluated.

I understand that you'd like for gopls to allow for reading and analysis of files intended for a different GOOS that the one that the editor is on, but given how packages are structured, you'd having to perform analysis on the matrix of build tags. That seems.... time consuming at best. Plumbing through a default tag set seems like an easy way to at least get folks moving again.

I'm happy to look into how to do that if need be! Please just let me know.

[evanphx]

Looks like it's also firing from net looking like:

/usr/local/Cellar/go/1.12/libexec/src/net/lookup_unix.go:81:24: undeclared name: cgoLookupHost