x/tools/gopls: support dynamic switching based on active editor with single build tag

[meling]

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

[firelizzard18]

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.