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

DylanSp · 2024-03-06T23:21:00Z

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

The text was updated successfully, but these errors were encountered:

adonovan · 2024-03-07T20:31:58Z

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 · 2024-03-07T22:53:02Z

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 · 2024-03-08T23:50:23Z

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 · 2024-04-23T16:46:52Z

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

gopherbot · 2024-04-24T09:05:59Z

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 · 2024-04-24T16:06:02Z

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 · 2024-04-24T22:17:45Z

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 · 2024-04-25T01:45:02Z

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 · 2024-04-25T02:19:05Z

Closing as dup of #60752.

DylanSp added gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository. labels Mar 6, 2024

gopherbot added this to the Unreleased milestone Mar 6, 2024

adonovan modified the milestones: Unreleased, gopls/v0.16.0 Mar 7, 2024

findleyr changed the title ~~x/tools/gopls: Renaming a type is not allowed when it has the same name as a parameter~~ x/tools/gopls: renaming a type is not allowed when it has the same name as a parameter Mar 12, 2024

adonovan closed this as completed Apr 25, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

DylanSp commented Mar 6, 2024

adonovan commented Mar 7, 2024

adonovan commented Mar 7, 2024

DylanSp commented Mar 8, 2024 •

edited

tttoad commented Apr 23, 2024

gopherbot commented Apr 24, 2024

adonovan commented Apr 24, 2024

DylanSp commented Apr 24, 2024 •

edited

tttoad commented Apr 25, 2024

adonovan commented Apr 25, 2024

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

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

Comments

DylanSp commented Mar 6, 2024

gopls version

go env

What did you do?

What did you see happen?

What did you expect to see?

Editor and settings

Logs

adonovan commented Mar 7, 2024

adonovan commented Mar 7, 2024

DylanSp commented Mar 8, 2024 • edited

tttoad commented Apr 23, 2024

gopherbot commented Apr 24, 2024

adonovan commented Apr 24, 2024

DylanSp commented Apr 24, 2024 • edited

tttoad commented Apr 25, 2024

adonovan commented Apr 25, 2024

DylanSp commented Mar 8, 2024 •

edited

DylanSp commented Apr 24, 2024 •

edited