x/tools/gopls: provide a way to run ExecuteCommand features in one step #40438
What version of Go are you using (
The text was updated successfully, but these errors were encountered:
We do still need to look into how these code action kinds work, and maybe we will use them. Still, I think that a client executing commands directly will always be prone to errors and incompatibilities, at least until the protocol has a way to tell the client which arguments should be provided to which commands.
I'm not sure if this is something that the protocol will support, but microsoft/language-server-protocol#642 and microsoft/language-server-protocol#430 are relevant. It may be worth filing an issue for this specifically, as I'm sure that every language has to deal with this issue.
Unless something changes, the only "correct" way to call fillstruct will be to first call codeAction, as that's the only correct way of getting the command and checking if it's available to call.
Code actions that apply convenience fixes were filtered by the start line so it wasn't possible to narrow the scope to a specific range. This change allows clients to send a specific range (or cursor position) to filter all fixes where the range doesn't intersect with the provided range. It also widens the diagnostic returned by fillstruct analysis. The idea is to provide a way to narrow the scope without breaking clients that do want to ask for code actions using the entire line. Updates golang/go#40438 Change-Id: Ifd984a092a4a3bf0b3a2a5426d3e65023ba4eebc Reviewed-on: https://go-review.googlesource.com/c/tools/+/244519 Run-TryBot: Pontus Leitzler <email@example.com> TryBot-Result: Gobot Gobot <firstname.lastname@example.org> Reviewed-by: Rebecca Stambler <email@example.com>
Yes, the purpose here would be to provide a way for the client to ask for
I think that would be needed in the case of
If the user want to extract to function they call
That's why I suggest adding
To clarify the intent here; It doesn't have to be client crafted calls to ExecuteCommand. Requiring another LSP roundtrip (like CodeLens or CodeAction) is also a way to implement it in a way so it acts as one step for the user.
Heschi had a suggestion on the latest tools call, for a potential way forward. That would be to add existing CodeLenses as CodeActions as well (opt-in, disabled by default). It would require each command to have a unique kind that can be sent from the client as
Adding unique kinds to
It could be tricky to fit some of the existing CodeLenses into a CodeAction basekind. I read somewhere (but lost the link) that the
According to LSP specification the entire set of kinds ".. is open and client needs to announce the kinds it support..." so it doesn't really prevent gopls from using a new base kind.
This change adds "go test" as a code action and also introduce the concept of explicit code actions, i.e. code actions that aren't returned to the client unless it explicitly ask for it. The purpose is to be able to have a mechanism that allows users to execute a specific command in one shot, and future CL:s will add more of the existing code lenses as explicit code actions. Code lenses can't be used directly since they lack the range/kind combo to make them unique. Updates golang/go#40438 Change-Id: I245df4e26c9e02e529662181e2c1bc44f999e101 Reviewed-on: https://go-review.googlesource.com/c/tools/+/259377 Trust: Rebecca Stambler <firstname.lastname@example.org> Trust: Peter Weinberger <email@example.com> Run-TryBot: Rebecca Stambler <firstname.lastname@example.org> TryBot-Result: Go Bot <email@example.com> gopls-CI: kokoro <firstname.lastname@example.org> Reviewed-by: Rebecca Stambler <email@example.com>
This CL lays the groundwork for future refactoring, by defining a formal (Go) interface for the set of commands provided by gopls in the workspace/executeCommand RPC. It then creates some boilerplate bindings via code generation. The intent is to, first of all, clean up our current usage of commands. Currently the 'specification' of a command is really split across internal/lsp/command.go, internal/lsp/source/command.go, and internal/lsp/source/code_lens.go. Changing a command signature might require altering all three of those files, and it's easy to get wrong. But also, we'd like to eventually be able to tell plugin authors that they can call our commands in an ad-hoc manner (meaning with arguments that they assign, rather than extract from a code lens). In order to do that, we need to be able to generate documentation for the command signature, and should also stop using positional arguments. This CL aims to solve that as well, by providing a commandmeta package that can be used for document generation. For golang/go#40438 Change-Id: I0d29de044e107d6e7b267f340879a5282f0b4944 Reviewed-on: https://go-review.googlesource.com/c/tools/+/289489 Trust: Robert Findley <firstname.lastname@example.org> Run-TryBot: Robert Findley <email@example.com> gopls-CI: kokoro <firstname.lastname@example.org> TryBot-Result: Go Bot <email@example.com> Reviewed-by: Rebecca Stambler <firstname.lastname@example.org> Reviewed-by: Heschi Kreinick <email@example.com>
Fully switch to the new generated command API, and remove the old dynamic command configuration. This involved several steps: + Switch the command dispatch in internal/lsp/command.go to go through the command package. This means that all commands must now use the new signature. + Update commandHandler to use the new command signatures. + Fix some errors discovered in the command interface now that we're actually using it. + Regenerate bindings. + Update all code lens and suggested fixes to new the new command constructors. + Generate values in the command package to hold command names and the full set of commands, so that they may be referenced by name. + Update any references to command names to use the command package. + Delete command metadata from the source package. Rename command.go to fix.go. + Update lsp tests to execute commands directly rather than use an internal API. This involved a bit of hackery to collect the edits. + Update document generation to use command metadata. Documenting the arguments is left to a later CL. + Various small fixes related to the above. This change is intended to be invisible to users. We have changed the command signatures, but have not (previously) committed to backwards compatibility for commands. Notably, the gopls.test and gopls.gc_details signatures are preserved, as these are the two cases where we are aware of LSP clients calling them directly, not from a code lens or diagnostic. For golang/go#40438 Change-Id: Ie1b92c95d6ce7e2fc25fc029d1f85b942f40e851 Reviewed-on: https://go-review.googlesource.com/c/tools/+/290111 Trust: Robert Findley <firstname.lastname@example.org> Run-TryBot: Robert Findley <email@example.com> gopls-CI: kokoro <firstname.lastname@example.org> TryBot-Result: Go Bot <email@example.com> Reviewed-by: Heschi Kreinick <firstname.lastname@example.org>
Update our docgen to include documentation for commands. This is done in an ad-hoc manner. We'll probably need to iterate on this as we go. For golang/go#40438 Change-Id: I0a6922aa2f5e7dc4c8a43e0f843ddb54971cbe44 Reviewed-on: https://go-review.googlesource.com/c/tools/+/290190 Trust: Robert Findley <email@example.com> Run-TryBot: Robert Findley <firstname.lastname@example.org> gopls-CI: kokoro <email@example.com> TryBot-Result: Go Bot <firstname.lastname@example.org> Reviewed-by: Heschi Kreinick <email@example.com>