x/tools/gopls: "renaming [method] is not possible because [package] has errors" #41870
What version are you using?
$ go version -m $(which gopls) /usr/local/google/home/bcmills/bin/gopls: devel +186f0220d0 Mon Oct 5 11:12:24 2020 -0400 path golang.org/x/tools/gopls mod golang.org/x/tools/gopls v0.5.1 h1:AF3Uh7HF08SZpKFfgJO6zfF3bbxyDXWqdkK4kMXiQ1o= dep github.com/BurntSushi/toml v0.3.1 h1:WXkYYl6Yr3qBf1K79EBnL4mak0OimBfB0XUf9Vl28OQ= dep github.com/google/go-cmp v0.5.1 h1:JFrFEBb2xKufg6XkJsJr+WbKb4FQlURi5RUcBveYu9k= dep github.com/sergi/go-diff v1.1.0 h1:we8PVUC3FE2uYfodKH/nBHMSetSfHDR6scGdBi+erh0= dep golang.org/x/mod v0.3.0 h1:RM4zey1++hCTbCVQfnWeKs9/IEsaBLA8vTkd0WVtmH4= dep golang.org/x/sync v0.0.0-20200625203802-6e8e738ad208 h1:qwRHBd0NqMbJxfbotnDhm2ByMI1Shq4Y6oRJo21SGJA= dep golang.org/x/tools v0.0.0-20200930165741-f1523d29dbb9 h1:1R38tQp22dcHpTKJPjgVa16FhlDy/kHEaCM/ndi/FIc= dep golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1 h1:go1bK/D/BFZV2I8cIQd1NKEZ+0owSTG1fDTci4IqFcE= dep honnef.co/go/tools v0.0.1-2020.1.5 h1:nI5egYTGJakVyOryqLs1cQO5dO0ksin5XXs2pspk75k= dep mvdan.cc/gofumpt v0.0.0-20200802201014-ab5a8192947d h1:t8TAw9WgTLghti7RYkpPmqk4JtQ3+wcP5GgZqgWeWLQ= dep mvdan.cc/xurls/v2 v2.2.0 h1:NSZPykBXJFCetGZykLAxaL6SIpvbVy/UFEniIfHAa8A=
with GNU Emacs 27.1 and eglot 20200830.1254.
Does this issue reproduce with the latest release?
What did you do?
Move the editor point to the method
(Note that references to that method elsewhere in the file are highlighted, so cross-references seem to be working more-or-less correctly.)
What did you expect to see?
Since references to the named method resolve successfully, those references should be renamed despite any other errors in the file.
What did you see instead?
The text was updated successfully, but these errors were encountered:
After a first look, it seems this applies only when trying to rename a method, and the reason that is is because when renaming a method gopls tries to
to keep the code compilable after the rename. If the package has errors we might miss some necessary renames and so just perform an incomplete rename. If anyone wants to take a look this is where a method is checked for a rename and this is where the constraints mentioned in documentation are put together.
@stamblerre or anyone else, do you have an idea is there is a safe way around this?