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: improve handling for build tags #29202
Comments
Bitten by this also, lost an hour trying to figure out why after migrating to |
I'm wondering whether this is the right issue to become the umbrella issue for our long-running discussion about context? |
This is killing me with integration tests that have build tags. Any workarounds known? |
@sjdweb current workaround I'm using is to set the GOFLAGS environment variable. This is the configuration I'm using in VS Code:
|
This was brought up on Tuesday's golang-tools call. @christiankiely - the "editor level" 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:
We also need:
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. |
Bitten by this as well. I use build tags to distinguish between normal builds and debug builds. Now VSCode reports |
Another populate use case: when using wire, there are two copies of the initializers:
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? |
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. |
As a data point, I'm experiencing this today in any package that picks up 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. |
Looks like it's also firing from
|
@evanphx I also found this issue. Now I develop the |
@zchee Ah! That makes a lot of sense, I'll start it with CGO_ENABLED=0 and see how it works. |
@evanphx |
@stamblerre |
I think we will still need special handling for build tags so that users don't need special configurations to get |
This and #49657 were the only relevant results for my internet searches, so, for historical reasons, my solution for (setenv "GOFLAGS" "-tags=linux,windows") Is there a plan to make something like this a permanent in |
@calebstewart That's insteresting. And, more puzzling thing is that AFAIK platform (os/arch) are special and go commands select them based on |
for vscode users, update your {
"go.toolsEnvVars": {
"GOOS": "js",
"GOARCH": "wasm"
}
} |
@hyangah interesting, it could have been some configuration specific to this project (it's a work project, and I'm not the one who configured it), then, but that seemed to be the best approximation of the suggestions I was seeing online. Admittedly, I'm not exactly sure why it worked for me either, but all I can say is that it did. 👀 |
I have a similar problem, I have separate files (
after adding the following tags I'll get a duplicate declaration error on these files because I'm declaring the same things in these 3 files. "gopls": {
"build.buildFlags": ["-tags=linux,windows,darwin"],
} |
@ahmafi I can reproduce the same error messages from vscode/gopls with a trivially simple project using containing 3 files: common.gopackage main
import "fmt"
func common() {
fmt.Println("This is common")
} xmain.go//go:build xmain
package main
import "fmt"
func main() {
fmt.Println("This is xmain")
common()
} ymain.go//go:build ymain
package main
import "fmt"
func main() {
fmt.Println("This is ymain")
common()
} With no gopls build flags defined, I get the "no packages found" message. If I add the following to settings.json, I get the duplicate declaration error. "gopls": {
"build.buildFlags": [
"xmain",
"ymain",
],
}, There are no errors reported when I run @stamblerre This is a major limitation for one of my current projects. I'd love to see a solution or a viable workaround. |
@Michael-F-Ellis you should be able to work on xmain OR ymain by setting just one of those two build tags, the same as you do when you run The critical missing feature for gopls is the ability to edit using multiple sets of build tags simultaneously. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This is largely a quality of life/tooling improvement. I've removed the build e2e tags in the test/e2e directory and explicitly made the existing `make test` rule only run in the ./pkg directory; it previously ran from the top-of-the-tree (which is totally reasonable). The two make targets `test` and `e2e` continue to test what they previously did. The motivation for this change was not having to futz with my gopls configuration when editing files in test/e2e. There are other ways to skin this cat that also involve no build tags at all. This satisfied my current needs. Ideally gopls gains build tag support: golang/go#29202
This is largely a quality of life/tooling improvement. I've removed the build e2e tags in the test/e2e directory and explicitly made the existing `make test` rule only run in the ./pkg directory; it previously ran from the top-of-the-tree (which is totally reasonable). The two make targets `test` and `e2e` continue to test what they previously did. The motivation for this change was not having to futz with my gopls configuration when editing files in test/e2e. There are other ways to skin this cat that also involve no build tags at all. This satisfied my current needs. Ideally gopls gains build tag support: golang/go#29202
Hello, Is this topic still in progress or should we not expect any improvement regarding this limitation? Thanks, |
Hi all, this issue deserves an update (and sorry @alexgille for missing your inquiry above). Let me summarize the current state of things: We know that support for multiple sets of build tags is one of the most desired features for gopls. Unfortunately, build tags pose a fundamental problem that we can't fix without changing many other things about gopls. Because several of gopls' algorithms rely on having an active graph of Even if that solution is acceptable for some users with small workspaces, it poses a significant burden on the code in an area where we have historically had a lot of bugs: package metadata tracking and package invalidation. I am currently trying to refactor that area of gopls and fix all the bugs. In gopls@v0.9.0 the representation of metadata was refactored, which contributed a piece of the performance improvements observed in that release. In gopls@v0.9.2, I'm trying to fix all the outstanding bugs we know about related to metadata. So here also, we are hesitant to throw more complexity at the problem. Longer term, an even higher priority for us is to make gopls scale better and load faster. In order to achieve this, we will inevitably need to break our dependence on the package graph. The first step toward this is rewriting key algorithms to be based on data structures that can be incrementally updated at the package level. Once we do this, the problem of handling multiple sets of build tags becomes tractable. So resolving this issue can't realistically happen soon, but is part of our longer terms goals for gopls. In the meantime, I think we can still improve the status-quo. For example:
|
For nvim-lspconfig users (with nvim-lsp-installer) following settings worked for me: lspconfig.gopls.setup {
settings = {
gopls = {
env = {
GOFLAGS = "-tags=windows,linux,unittest"
}
}
}
} with files looking like thing_test.go: //go:build unittest
package thing_test and thing.go package thing all lsp features work. |
Cross-posting from golang/vscode-go#1799: Is there an alternative without relying on setting env variable in VS code settings? Maybe a top-level comment in the file? This seems to have been mentioned at the begging of this thread: #29202 (comment), #29202 (comment) (there are many messages, sorry if it has already been mentioned/answered) |
@eric-burel as a workaround you can open projects in different VS Code instances. WASM client code can be placed somewhere in project dir and can have it's own workspace settings in |
For emacs and eglot users: (setq-default eglot-workspace-configuration
'((:gopls
(:ui.completion.usePlaceholders . t)
(:ui.diagnostic.staticcheck . t)
(:build.buildFlags . ["-tags" "sometag"])))) |
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.
The text was updated successfully, but these errors were encountered: