x/tools/gopls: renaming a type is not allowed when it has the same name as a parameter

[DylanSp]

gopls version

golang.org/x/tools/gopls v0.14.2

go env

$ go env
GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/home/codespace/.cache/go-build'
GOENV='/home/codespace/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.21.7'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/dev/null'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build2156371313=/tmp/go-build -gno-record-gcc-switches'

What did you do?

Attempted to rename a struct type to a new name that was the same as existing parameter names, using VSCode's "Rename Symbol" action.

type myData struct {
	someField int
}

func standaloneFunc(data myData) {
	// intentional no-op
}

I attempted to rename myData to data.

https://github.com/DylanSp/gopls-rename-issue-repro/blob/main/main.go demonstrates the issue; it also happens with method receivers.

What did you see happen?

The following error message:

gopls-rename-issue-repro/main.go:3:6: renaming this type "myData" to "data" gopls-rename-issue-repro/main.go:7:13: would cause this reference to become shadowed gopls-rename-issue-repro/main.go:7:7: by this intervening var definition

What did you expect to see?

The myData type to be renamed to data. I think this should always be valid, but I'm not 100% positive; if I manually rename myData to data in the example code, it compiles.

Editor and settings

VSCode version 1.87.0.
VSCode Go extension v0.41.1.

Logs

[Info  - 11:19:56 PM] 2024/03/06 23:19:56 go info for /workspaces/gopls-rename-issue-repro
(go dir /workspaces/gopls-rename-issue-repro)
(go version go version go1.21.7 linux/amd64)
(valid build configuration = false)
(build flags: [])
(selected go env: [GO111MODULE=, GOCACHE=/home/codespace/.cache/go-build, GOFLAGS=, GOMODCACHE=/go/pkg/mod, GOPATH=/go, GOPRIVATE=, GOROOT=/usr/local/go, GOWORK=])


[Info  - 11:19:56 PM] 2024/03/06 23:19:56 go/packages.Load #1
	snapshot=0
	directory=file:///workspaces/gopls-rename-issue-repro
	query=[./ builtin]
	packages=2

[Info  - 11:19:56 PM] 2024/03/06 23:19:56 go/packages.Load #1: updating metadata for 1 packages

[Error - 11:19:56 PM] Request textDocument/semanticTokens/range failed.
  Message: semantictokens are disabled
  Code: 0 
[Error - 11:19:57 PM] Request textDocument/semanticTokens/full failed.
  Message: semantictokens are disabled
  Code: 0 
[Error - 11:20:21 PM] Request textDocument/rename failed.
  Message: gopls-rename-issue-repro/main.go:3:6: renaming this type "myData" to "data"
gopls-rename-issue-repro/main.go:7:13:	would cause this reference to become shadowed
gopls-rename-issue-repro/main.go:7:7:	by this intervening var definition
  Code: 0 

[adonovan]

My first thought was that this bug was fixed by https://go.dev/cl/544035 since I can't reproduce it at master... but I can't reproduce it at v0.14.2 either:

xtools$ git co gopls/v0.14.2
HEAD is now at 1bf163756e gopls: update go.mod for v0.14.2-pre.1

xtools$ cat b.go
package tools

type myData struct {
	someField int
}

func standaloneFunc(data myData) {
	// intentional no-op
}

xtools$ go run ./gopls/ rename ./b.go:#84 data     #84 is in "myData" parameter type
package tools

type data struct {
	someField int
}

func standaloneFunc(data data) {
	// intentional no-op
}

xtools$ go run ./gopls/ rename ./b.go:#75 myData     #75 is in "data" parameter var name
package tools

type myData struct {
	someField int
}

func standaloneFunc(myData myData) {
	// intentional no-op
}

I'll keep investigating...

[adonovan]

What you are describing is definitely a bug--the renaming should succeed--but unfortunately I can't reproduce this at all using v0.14.2 or v0.15.1; using the function or the method; or renaming the parameter's type to match the name, or vice versa.

[DylanSp]

Well, it's good to know that it's definitely a bug and that there aren't any weird corner cases of the language that would make the renaming unsound.

I enabled the -rpc.trace flag for gopls and got the following logs:

[Trace - 23:48:44.554 PM] Sending request 'textDocument/prepareRename - (38)'.
Params: {"textDocument":{"uri":"file:///workspaces/gopls-rename-issue-repro/main.go"},"position":{"line":2,"character":8}}


[Trace - 23:48:44.555 PM] Received response 'textDocument/prepareRename - (38)' in 0ms.
Result: {"range":{"start":{"line":2,"character":5},"end":{"line":2,"character":11}},"placeholder":"myData"}


[Trace - 23:48:49.949 PM] Sending request 'textDocument/documentHighlight - (39)'.
Params: {"textDocument":{"uri":"file:///workspaces/gopls-rename-issue-repro/main.go"},"position":{"line":2,"character":8}}


[Trace - 23:48:49.949 PM] Sending request 'textDocument/rename - (40)'.
Params: {"textDocument":{"uri":"file:///workspaces/gopls-rename-issue-repro/main.go"},"position":{"line":2,"character":8},"newName":"data"}


[Trace - 23:48:49.950 PM] Received response 'textDocument/documentHighlight - (39)' in 1ms.
Result: [{"range":{"start":{"line":2,"character":5},"end":{"line":2,"character":11}},"kind":1},{"range":{"start":{"line":6,"character":12},"end":{"line":6,"character":18}},"kind":1},{"range":{"start":{"line":10,"character":25},"end":{"line":10,"character":31}},"kind":1}]


[Error - Received] 23:48:49.950 PM #40 gopls-rename-issue-repro/main.go:3:6: renaming this type "myData" to "data"
gopls-rename-issue-repro/main.go:7:13:	would cause this reference to become shadowed
gopls-rename-issue-repro/main.go:7:7:	by this intervening var definition


[Error - 11:48:49 PM] Request textDocument/rename failed.
  Message: gopls-rename-issue-repro/main.go:3:6: renaming this type "myData" to "data"
gopls-rename-issue-repro/main.go:7:13:	would cause this reference to become shadowed
gopls-rename-issue-repro/main.go:7:7:	by this intervening var definition
  Code: 0 

Doesn't seem like there's any new information there, though.

[tttoad]

@adonovan I wrote test cases on the master branch to replicate the issue.
I can provide PR to fix this.

[gopherbot]

Change https://go.dev/cl/581277 mentions this issue: gopls/rename: Support for renaming parameters and types when the type and parameter have the same name.

[adonovan]

Can you confirm that this problem still exists in a gopls built with go1.22 or later? I think this is likely a duplicate of #60752 which was fixed in go1.22.

[DylanSp]

This appears to be fixed now, using gopls v0.15.2. I don't know if that was built with go1.22 or not.

Versions of other related tools:

• VSCode: 1.88.1
• VSCode Go extension: v0.41.4

go env output:

$ go env
GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/home/codespace/.cache/go-build'
GOENV='/home/codespace/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.22.2'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/dev/null'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build4182857365=/tmp/go-build -gno-record-gcc-switches'

[tttoad]

Can you confirm that this problem still exists in a gopls built with go1.22 or later? I think this is likely a duplicate of #60752 which was fixed in go1.22.

I built gopls with go1.22.2 and it works.

[adonovan]

Closing as dup of #60752.