Support for test flags when calling gopls packages command

[firelizzard18]

When vscode calls the gopls packages command to list tests, is it feasible to pass testFlags? The test flags could include -tags which could change which tests are available, causing a mismatch between what the test explorer reports and what can actually be executed with the given test flags. If a CL for #1904 is merged then we'd also have benchmark flags. Alternatively, we could explicitly exclude -tags from testFlags (and benchFlags if that happens). I think we should do one or the other (or perhaps one then the other) because otherwise someone is inevitably going to try running tests with -tags in testFlags and it be buggy.

[firelizzard18]

CC @hyangah @findleyr

[findleyr]

Hmm, I think the Packages command should ideally query the packages that gopls sees.

If users want to operate on specific -tags, they should set that in their "buildFlags" gopls setting.

[firelizzard18]

To be clear I was thinking of an optional parameter that would modify Packages' behavior. Should I take your comment to mean, "Packages' behavior should not be modifiable in that manner"? I think that's a reasonable decision I just want to be sure I understand. I'm not sure how the optional behavior modification would work; given my (admittedly limited) understanding of how gopls handles tags, snapshots, views, etc it seems like "interpret this code with a transient set of tags" really doesn't fit the model.

That being said, we may need to consider changing how build flags and test flags are handled. As @hyangah says here, currently buildFlags are ignored for tests if testFlags are specified. Regardless of the official stance on how -tags should be handled, the current behavior leads to what I consider to be a bug which you can see demonstrated by this example repo. Given that go.buildFlags includes -tags=bar and go.testFlags is not empty and does not include tags, TestBar is included in Packages but can't be run via the extension without adding tags to the test flags. That's less than ideal especially if we're going to tell users they should set tags in build flags, not in test flags.

Maybe go.buildTags should be special and instead of "This is propagated to the language server if gopls.build.buildFlags is not specified" we should always propagate that setting and tell users not to put -tags in build flags or test flags.