x/tools/gopls: generate method stubs for a given interface

[marwan-at-work]

Proposal (TL;DR):

It would be great if Gopls implemented a way where a user:

1. Moves the cursor to a type declaration
2. Gets a list of all interface declarations within the workspace
3. Picks an interface for gopls to generate method stubs for.

See this video for a demonstration: https://vimeo.com/394345925

Details

A common feature that Go and other typed languages have is to generate method stubs for an interface that a type wants to implement.

For most languages, the concrete type must declare what interface it intends to implement. This makes it easier for tools to generate those stubs.

For an example, take a look at this screenshot from TypeScript in VSCode:

Notice that type X implements Greeter and therefore the dropdown knows which method it needs to stub out.

In Go, it is impossible to know that because interfaces are implicitly implemented.

Therefore, generating method stubs require a two step process:

1. You pick the interface declaration that you'd like an interface to implement
2. You pick the concrete type you'd like to add method-stubs to.

Therefore, I wrote a tool that that can do both of these features: https://github.com/marwan-at-work/impl

Here's a video of how I integrated the tool with VSCode locally to demonstrate the same feature working for Go: https://vimeo.com/394345925

However, the tool uses go/packages directly and is obviously a standalone that doesn't leverage gopls with its cache and environment. Therefore, I suggest we make this a feature within gopls.

If this is something worth including, I'd be very happy to port the work I did into gopls (with a little help).

Unfortunately, the LSP protocol does not have an explicit message for "generating method stubs", and so we a few options were brought up in slack that I want to highlight here:

1. Use CodeAction -> refactor.extract / quickfix
2. Use noneStandardRequest
3. Hacking around Autocomplete

cc: @stamblerre @hyangah -- I'm not sure which of the above is the best way, but I'm happy to take on whichever you think is best 👍

PS. Note that this tool used to exist in GOPATH mode using https://github.com/josharian/impl but as far as I know, it is not modules aware and lacked a number of features such as "listing available interfaces" and "automatically adding import paths"

[ianthehat]

Another possibility would be to add it as a quick fix to the

*MyImplementation does not implement MyInterface (missing MyMethod method)

type checking error.
You could intentionally trigger it with the

var _ MyInterface = (*MyImplementation)(nil)

stanza if needed.
Not saying this is the best way, just adding it to the list for consideration.

[marwan-at-work]

@ianthehat Would it be possible to expand it to wherever a concrete type is being casted as an interface? For example:

function GetWriter() io.Writer {
  return &myWriter{} // quick fix: implement io.Writer on *myWriter
}

function takeReader(r io.Reader) { ... }

takeReader(&myReader{}) // quick fix: implement io.Reader on *myReader

Similar to rename, it should only do it if the concrete type was defined within the workspace/module boundaries.

[gopherbot]

Change https://golang.org/cl/274372 mentions this issue: gopls,internal/lsp: Implement method stubbing via CodeAction

[gopherbot]

Change https://golang.org/cl/279412 mentions this issue: lsp/source: Update SuggestedFixFunc's signature to include source.Snapshot.

[robert-zaremba]

Any ETA for this feature? go-impl has many problems (eg nested interfaces, package import alias ...)

[marwan-at-work]

@robert-zaremba there's an open CL in gopls and is pending review: cc @findleyr

[hyangah]

@marwan-at-work Sorry for letting you wait so long. Now adding custom gopls commands became easy. What's the advantage of "CodeAction -> refactor.extract / quickfix" compared to the custom gopls command as you did to replace the use of gopkgs before.

Related: see golang/vscode-go#1547 (pending CL: https://go-review.googlesource.com/c/vscode-go/+/330850/) that improves the current UX implemented using https://github.com/josharian/impl. Wonder if we can simply replace the old tool invocation once this is implemented as a gopls's custom command.

[marwan-at-work]

@hyangah I think there's a couple of differences:

1. The "Add Import" needs each editor to implement. While quickfix (I imagine) is available in all/most editors with LSP support.
2. In the case of this issue, a custom command will either require the user to write out the entire import path + interface name, or have VSCode list all the possible interfaces within a workspace (I prefer the latter one if it's acceptable) while the quickfix relies on a common convention of having the user write a concrete<->interface type assertion like var _ io.Writer = &myWriter{} AKA a poor man's "implements" keyword.

Wonder if we can simply replace the old tool invocation once this is implemented as a gopls's custom command.

We can certainly do that. However, the quickfix vs custom command part of the code is actually not where the complexity lies. It's the whole implementation of generating code within the environment and adding the proper import paths, which are things that josharian/impl never did AFAIK.

With all of that said, we can definitely have both a quickfix and a custom command that just re-uses the same logic 🎉

PS. I see in the CL you linked, you actually use a quick pick by searching the workspace for interface definitions (but I imagine that's not enough because you might want to implement interfaces of dependencies or std lib?). But in any case, I think my CL should hopefully provide the basis for both quickPick and quickFix.

[hyangah]

PS. I see in the CL you linked, you actually use a quick pick by searching the workspace for interface definitions (but I imagine that's not enough because you might want to implement interfaces of dependencies or std lib?).

I don't know why :-) but currently workspace symbol search includes symbols from dependencies.

But in any case, I think my CL should hopefully provide the basis for both quickPick and quickFix.

Yes, quick fix is a nice addition, but that doesn't replace the current vscode workflow. I see that part of your cl can be reused for the custom command that takes a position info & a desired interface name (import path + name).

[gopherbot]

Change https://go.dev/cl/389654 mentions this issue: internal/lsp/source: support stubbing concrete type params

[gopherbot]

Change https://go.dev/cl/404655 mentions this issue: internal/lsp/analysis/stubmethods: recognize *ast.CallExpr

[marwan-at-work]

I don't know why :-) but currently workspace symbol search includes symbols from dependencies.

@hyangah I am getting back to this a little bit and I see that this is actually the workspace/symbol request that does the search. However, the standard library is only included if your workspace happens to import those standard library packages. Therefore, if you import io but not bufio, then you only see results from the io package and not the bufio one.

I think it's potentially solvable by just making sure we search all standard library packages on the gopls side.

One thing that is quite confusing however is that the SymbolKind in gopls (or the LSP) starts counting from 1 but the SymbolKind in VSCode starts counting from 0. Is that something that's known or am I potentially looking at the wrong place?

VSCode: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/d63ce78a85c1b9086eaf8c96499a30936b625495/types/vscode/index.d.ts#L3048

Gopls/LSP: https://github.com/golang/tools/blob/904e24e9fcf9e04175d563e5112b8264262acbb0/internal/lsp/protocol/tsprotocol.go#L6334

[findleyr]

@marwan-at-work we can definitely make that improvement to workspace symbols.

I'm not sure about that typescript link, but in the protocol Interface is definitely 11:
https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#symbolKind

Also, we do get the correct interpretation in LSP clients.

[hyangah]

@marwan-at-work

One thing that is quite confusing however is that the SymbolKind in gopls (or the LSP) starts counting from 1 but the SymbolKind in VSCode starts counting from 0. Is that something that's known or am I potentially looking at the wrong place?

Yes, LSP symbol kind is different from vscode symbol kind. Language clients are supposed to translate them (https://github.com/microsoft/vscode-languageserver-node/blob/f97bb73dbfb920af4bc8c13ecdcdc16359cdeda6/client/src/common/protocolConverter.ts#L838)