Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
DylanSp opened this issue Mar 6, 2024 · 9 comments
Labels
gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone

Comments

@DylanSp
Copy link

DylanSp commented Mar 6, 2024

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 
@DylanSp 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 gopherbot added this to the Unreleased milestone Mar 6, 2024
@adonovan
Copy link
Member

adonovan commented Mar 7, 2024

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
Copy link
Member

adonovan commented Mar 7, 2024

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.

@adonovan adonovan modified the milestones: Unreleased, gopls/v0.16.0 Mar 7, 2024
@DylanSp
Copy link
Author

DylanSp commented Mar 8, 2024

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.

@findleyr 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
@tttoad
Copy link

tttoad commented Apr 23, 2024

image

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

@gopherbot
Copy link
Contributor

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
Copy link
Member

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
Copy link
Author

DylanSp commented Apr 24, 2024

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
Copy link

tttoad commented Apr 25, 2024

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
Copy link
Member

Closing as dup of #60752.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Development

No branches or pull requests

5 participants