Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/tools/gopls: does not handle build tags #29202

Open
stamblerre opened this issue Dec 12, 2018 · 17 comments

Comments

Projects
None yet
10 participants
@stamblerre
Copy link
Contributor

commented Dec 12, 2018

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

This comment has been minimized.

Copy link

commented Apr 24, 2019

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

This comment has been minimized.

Copy link
Member

commented Apr 28, 2019

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

@sjdweb

This comment has been minimized.

Copy link

commented May 1, 2019

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

@christiankiely

This comment has been minimized.

Copy link

commented May 1, 2019

@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 comment has been minimized.

Copy link
Member

commented May 2, 2019

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

This comment has been minimized.

Copy link

commented May 11, 2019

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

This comment has been minimized.

Copy link

commented May 15, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented May 15, 2019

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

This comment has been minimized.

Copy link
Contributor

commented May 25, 2019

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

This comment has been minimized.

Copy link
Contributor

commented May 25, 2019

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

@zchee

This comment has been minimized.

Copy link
Contributor

commented May 26, 2019

@evanphx I also found this issue.
The workaround is launch gopls use CGO_ENABLED=0 or something. Note that might be vscode can't that workaround AFAIK. Also not solved if set CGO_ENABLED=0 to env. Because it is late to place.
#29202 (comment)

Now I develop the client side for IDE written in Go, it's implemented set some env to launch gopls binary using set to exec.Command.Env. I did solve the use it.
Anyway, We should including CGO_ENABLED=0 to gopls send Build info.

@evanphx

This comment has been minimized.

Copy link
Contributor

commented May 26, 2019

@zchee Ah! That makes a lot of sense, I'll start it with CGO_ENABLED=0 and see how it works.

@zchee

This comment has been minimized.

Copy link
Contributor

commented May 27, 2019

@evanphx
Also, I was send CL (but I think still not user friendly) for support build tags.
https://go-review.googlesource.com/c/tools/+/178782
It solved if your code needs any build tags such as purego, static.

@zchee

This comment has been minimized.

Copy link
Contributor

commented May 27, 2019

@evanphx
FYI, ref for your issue root cause:
#31705

@zchee

This comment has been minimized.

Copy link
Contributor

commented Jun 4, 2019

@stamblerre

This comment has been minimized.

Copy link
Contributor Author

commented Jun 5, 2019

I think we will still need special handling for build tags so that users don't need special configurations to get gopls features in files tagged for different build systems.

@zchee

This comment has been minimized.

Copy link
Contributor

commented Jun 5, 2019

@stamblerre
I see, totally agreed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.