x/tools/gopls: add support for more code lenses

[stamblerre]

We should support the textDocument/codeLens request type.
The VS Code Go extension has a number of code lenses we could add as a starting point.
See microsoft/vscode-go#3003.

[stamblerre]

@hyangah suggested that we could use code lenses to offer the user an option to start a local godoc server.

[hyangah]

Another code lens feature VS Code Go provides is 'run test' and 'debug test' code actions. They are currently through a separate GoDocumentSymbolProvider that invokes go-outliner underneath. Would be nice if gopls provides the code action as well.

[martskins]

I'm keen to give the run test code lens a try. I currently have a basic implementation that uses a command (much like the go generate code lens does) to run the test.
The question now is what we want to do with the output of that command, as it stands now I just call ShowMessage with test passed or test failed based on the output of the command, but maybe we want to show the full output of the test somewhere (if it fails). Any ideas about this last point?

[stamblerre]

That's awesome @martskins - please do send a changelist when you're ready :) I think the show message is fine for now (we do something similar for go generate here). You can also use the progress reporting, which I believe gives access to the output channel.

Ideally, we'd be able to write to the VS Code output channel like the extension does, but LSP doesn't support that yet. Looks like @marwan-at-work, who wrote the go generate code lens, has already filed that request: microsoft/language-server-protocol#945.

[marwan-at-work]

Running tests is tricker than running go generate because if the tests fail, you really wanna look at why a test fails (especially if you're running table tests or package-level tests, you wanna know which test exactly failed)

In go generate we are using the WorkDoneProgress UI (which only shows one log at a time and disappears right away) so the tests won't work for that.

go generate however falls back to the gopls window-output if WorkDoneProgress is not supported by the editor.

The problem with the gopls window-output is twofold:

1. You can't have the LSP tell the Client to "show the window now" -- so the user must know how to find it.

2. That window is cluttered with LSP specific logs (for a good reason ) and even the go-generate output is actually specially formatted for the LSP Inspector.

So from VSCode's perspective, using that will actually be a much less friendly user experience than what's currently in place until the proposal Rebecca mentioned is accepted and implemented in clients.

I believe it was mentioned to me at some point that you can do custom requests and each client will have to implement that custom request, so that's another route but im not familiar with it :)

[hyangah]

For VS Code, there is also 'debug test' code lens that works closely with the debugger. I expect that will be hard to delegate to gopls. For VS Code, we will probably end up using this as a hint to detect 'Test*', 'Benchmark*' functions and test command arguments. Then, translate it back to our own VS Code commands from lsp middleware, instead of delegating the test run to gopls.