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: support dynamic switching based on active editor with single build tag #65089

Open
meling opened this issue Jan 13, 2024 · 1 comment
Labels
FeatureRequest gopls/metadata Issues related to metadata loading in gopls gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone

Comments

@meling
Copy link

meling commented Jan 13, 2024

gopls version

Irrelevant

go env

Irrelevant

What did you do?

To reproduce, consider a package cipher with three files:

cipher/
├── rot13.go
├── rot13_sol.go
└── rot13_test.go

In rot13.go we have a template (empty implementation) that is supposed to fail tests:

//go:build !solution

package cipher

type rot13Reader struct{ r io.Reader }

func (r rot13Reader) Read(p []byte) (n int, err error) {
	return 0, nil
}

In rot13_sol.go we have an implementation (details excluded) that is supposed to pass tests:

//go:build solution

package cipher

In rot13_test.go we have tests:

func TestRot13(t *testing.T) { ... }

From the command line, I can test that the template version fails because the solution tag is not set:

% go test
--- FAIL: TestRot13 (0.00s)
    rot13_test.go:33: rot13.Read("Go programming is fun."): (-want +got):
...

Similarly, the rot13_sol.go version passes the tests because the solution tag is set:

% go test -tags solution
PASS
ok  	lab1/cipher	0.280s

This approach is convenient because I can keep the template, test, and solution in the same folder.

What did you see happen?

With VSCode, I can do:

    "gopls": {
        "buildFlags": [
            "-tags=solution"
        ]
    },

To enable compilation of the rot13_sol.go file, and switch to -tags=!solution to enable compilation of the rot13.go file.

However, it is not possible to avoid the error:

No packages found for open file ... /lab1/cipher/rot13.go.
This file may be excluded due to its build tags; try adding "-tags=<build tag>" to your gopls "buildFlags" configuration
See the documentation for more information on working with build tags:
https://github.com/golang/tools/blob/master/gopls/doc/settings.md#buildflags-string.

It is also annoying to have to switch the build tag in the configuration to take advantage of gopls, e.g., to rename a field or type.

What did you expect to see?

For this simple case with a single build tag, it should be possible to dynamically switch between compiling for the build tag and its negation based on the active editor window, removing the error from source files whose tag is the negation.

I'm opening this issue separately from the global issue about improving build tags support (#29202) to find out if this is a common enough pattern that makes it worth fixing on its own.

It seems unlikely that we will get support for advanced constraints like //go:build (solution || experiment) because of the complexity involved, at least in the near term. So one question would be if users would expect this to work too and thus become confused when it doesn't. One counter-argument is that detecting such constraints and providing an appropriate error message should be possible.

Editor and settings

No response

Logs

No response

@meling meling added gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository. labels Jan 13, 2024
@gopherbot gopherbot added this to the Unreleased milestone Jan 13, 2024
@adonovan adonovan added the gopls/metadata Issues related to metadata loading in gopls label Jan 16, 2024
@hyangah hyangah modified the milestones: Unreleased, gopls/backlog Jan 17, 2024
@firelizzard18
Copy link
Contributor

firelizzard18 commented Jun 22, 2024

I would be happy with a solution that required some configuration. I'm imagining some config value like gopls.userBuildConfigs. I'm not sure exactly what that should look like, maybe a list of custom tags, or maybe a list of configurations. That doesn't solve the problem that creating a build for every permutation could get very expensive, but I have no objection to adding a few lines of configuration.

I guess I was essentially saying I'd be happy with #65757. Though I think it's worth considering something in between - giving hints to gopls as opposed to completely specifying the build, or completely relying on gopls to infer it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
FeatureRequest gopls/metadata Issues related to metadata loading in gopls gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Development

No branches or pull requests

6 participants