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: rename fails with "conflicts with var in same block" when the new identifier already exists #41852

bcmills opened this issue Oct 7, 2020 · 4 comments


Copy link

@bcmills bcmills commented Oct 7, 2020

This is related to (but slightly different from) #41851.

What did you do?

Follow the same steps to reproduce as for #41851, but for step (1) use a declared identifier instead of an undeclared one.

What did you expect to see?

The identifier at the point, as well as all references to it, should be renamed, despite the fact that the new identifier conflicts with the existing declaration.

The resulting program should now have a redeclared in this block error (, which the user may resolve by removing one or the other of the conflicting declarations.

What did you see instead?

[client-request] (id:41) Wed Oct  7 14:54:24 2020:
(:jsonrpc "2.0" :id 41 :method "textDocument/rename" :params
					 (:uri "file:///tmp/tmp.Ih8P4GysfM/")
					 (:line 14 :character 24)
					 :newName "errno"))
[server-reply] (id:41) ERROR Wed Oct  7 14:54:24 2020:
(:jsonrpc "2.0" :error
					(:code 0 :message "renaming this var \"errNo\" to \"errno\"	conflicts with var in same block")
					:id 41)
@gopherbot gopherbot added this to the Unreleased milestone Oct 7, 2020
@bcmills bcmills changed the title x/tools/gopls: rename fails when the new identifier already exists x/tools/gopls: rename fails with "conflicts with var in same block" when the new identifier already exists Oct 7, 2020
@stamblerre stamblerre removed this from the Unreleased milestone Oct 8, 2020
@stamblerre stamblerre added this to the gopls/unplanned milestone Oct 21, 2020
Copy link

@muirdm muirdm commented Nov 21, 2020

I'm not sure this would be safe behavior in general. Consider a case like:

func _(greatName int) int {
  badName := 123

  greatName = badName - greatName

  // lots of other code

  return badName

The user is looking at the bottom of the function and really doesn't like badName. They lsp-rename it to greatName without realizing there is already a greatName. Suddenly all the uses of badName and greatName would become indistinguishable.

Copy link
Member Author

@bcmills bcmills commented Nov 22, 2020

... that's what undo is for‽

Copy link

@stamblerre stamblerre commented Nov 22, 2020

What if the user doesn't notice their mistake to undo it?

I agree with @muirdm that we can't support this case by default. Maybe with a -force flag on the command-line or something like that.

Copy link

@muirdm muirdm commented Nov 22, 2020

Also remember that rename applies to the entire module including files not open in your editor. If the user is in the middle of a big change with many modified files then a botched rename might be impossible to undo automatically.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants