commit 6b4ee4d563931a9707089260d4d41df4d08906a0
author Hana (Hyang-Ah) Kim <hyangah@gmail.com> Tue Oct 31 10:34:41 2023 -0400
committer Hyang-Ah Hana Kim <hyangah@gmail.com> Wed Nov 01 18:05:35 2023 +0000
tree de8fe34d9fb55db328533263893e5937bea75d2a
parent bf75c9fba7ff8a213c0b10b8907faba44f03e3d8

src/goFillStruct: remove Go: Fill struct command

VSCode's `editor.action.codeAction` provides a unified way
of accessing refactoring features, including "fill struct".

Gopls returns the appropriate fill struct options based on
the selection or cursor position when invoked with

"args": {
  "kind": 'refactor.rewrite',
}

https://code.visualstudio.com/docs/editor/refactoring#_keybindings-for-code-actions

We no longer require a separate fillstruct tool.

Delete the 'fill struct' tests. I hoped we could move these
tests to the gopls integration test, but it turned out
that is more complicated than I thought.

- Starting a VS Code editor instance is costly, so our integration
test starts the editor only once and restarts the gopls instances
for each test suite or test case.

- VSCode does not expose a way to close text document explicitly
by design. We can close visible editors, tabs, or tab groups
and make them disappear (as many stackoverflow posts suggest),
but VSCode keeps open text documents internally for some time
(and some hard-coded eviction age limit like 3minutes).

Reference: https://github.com/microsoft/vscode/issues/192308

- As a result, when a new Gopls instance starts, the editor
(LSP client) sends didOpen messages for the documents open
for previous testing. These documents belong to different
modules, and Gopls considers this misconfiguration.

- Fill struct is implemented as diagnostics. When we trigger
code action requests, Gopls tries to compute diagnostics first.
Unfortunately, gopls thinks the workspace is misconfigured,
produces various diagnostics about all the documents we've
ever opened in our integration test, and fails to suggest
or run fill struct action before timeout.

We can consider
- wait for gopls to support multiple-modules setup (aka
zero config gopls). That will handle the left-over files better.
- rearrange the test dataset to be in one workspace (go.work,
or a single module),
- arrange the integration test to work on a copied test data
and clean up used files at the end of every test. Still unclear
how quickly VSCode detects deleted files and invalidates the
contents in memory though, or
- arrange the lsp client middleware to hijack didOpen notification
and filter out messages about unwanted files during testing.

But given that the extension doesn't do anything special
beyond invoking the codeaction, I am not sure if we need to add
more complexity right now if the future gopls can handle this
better. So, I am dropping the tests now.

Fixes golang/vscode-go#2107

Change-Id: Ib5659274ae6bd7d25c7b3cdd432f2d5c17e0e30d
Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/538755
TryBot-Result: kokoro <noreply+kokoro@google.com>
Commit-Queue: Hyang-Ah Hana Kim <hyangah@gmail.com>
Reviewed-by: Suzy Mueller <suzmue@golang.org>