x/tools/gopls: renaming method of an in-use interface fails

[wtlangford]

What version of Go are you using (go version)?

$ go version
go version go1.13 darwin/amd64

$ gopls version
golang.org/x/tools/gopls v0.1.6
    golang.org/x/tools/gopls@v0.1.6 h1:jXi39uPnkIKQKqLUsZqznHkHyLqTXqjMId0kTrakGMI=

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE="off"
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/wlangford/Library/Caches/go-build"
GOENV="/Users/wlangford/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/wlangford/src/go"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.13/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.13/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/wc/0nx11dxn5qqb_2tjyr7pyk900000gp/T/go-build613974333=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Minimal example:
https://play.golang.org/p/sDBH3VQY5TF

Attempt to rename the X.A() method using gopls.

What did you expect to see?

X.A, and impl.A should be renamed

What did you see instead?

gopls reports an error:

Request textDocument/rename failed.
Message: internal error: during renaming of abstract method func (goplsexample.X).A() int	changedMethods=false, coupled method=func (goplsexample.impl).A() int	Please file a bug report
Code: 0 

[gopherbot]

Thank you for filing a gopls issue! Please take a look at the Troubleshooting guide, and make sure that you have provided all of the relevant information here.

[ianthehat]

In general I am not sure that is actually viable.
There is nothing that tells us that impl.A exists solely to implement X.A, it seems kind of obvious in a small example but it is not in the larger context.
Consider for example https://play.golang.org/p/YPivBBZLhZ8
Now if you rename X.A, and it renames impl.A, impl now no longer implements Y, which maybe it is supposed to do.
Also, should it rename impl2.A when there is no evidence at all that impl2 was supposed to implement X rather than Y?

[wtlangford]

I don't disagree. The only reason I tried it on the interface at all was in response to a message from gopls when I tried it on the implementation (in retrospect, I probably shouldn't have expected that to work either...).

The message from gopls was

Message: renaming this method "A" to "B"	would make goplsexample.impl no longer assignable to interface X	(rename goplsexample.X.A if you intend to change both types)

Maybe that message is the actual issue, directing users to try a thing that probably isn't reasonable.

[ianthehat]

I guess we should think what the ideal experience is.
Maybe when you try to rename the interface method, it should warn you about the places it breaks the code, but allow you to apply the rename anyway.
It could then look at the build breaks, and see if it could stack up some more renames that you can choose to apply to fix them again.

[leonardochaia]

Is there a workaround for doing this kind of rename? assuming a simple example like the one provided: just an interface and an implementation.
Acknowledging that it may break other interface implementations?