go: x/tools/cmd/gorename: doesn't work outside $GOPATH

What version of Go are you using (go version)?

go1.11

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

linux/amd64

What did you do?

Tried running gorename in a project outside of $GOPATH, using vscode-go and also manually. Both times the program errors with:

$ gorename -from ./world.go::World -to "Warudo"
gorename: can't find package containing /home/vhns/projects/phys/world.go

Commands work as expected when run on the same project inside the $GOPATH.

What did you expect to see?

The symbol being renamed.

What did you see instead?

An error message claiming the package could not be found.

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 63
  • Comments: 34 (18 by maintainers)

Commits related to this issue

Most upvoted comments

Related CL https://golang.org/cl/182585 for gopls was recently merged.

In the near term I’d be happy with a gorename that only works inside a given module. This seems like a reasonable goal given that the module system doesn’t provide any mechanism to know who the users of a module are.

Can anyone working on gopls say how they see that fitting into the gorename story?

Is there any update on this issue?

@douglarek: gopls is pretty close to being able to replace gocode, but we don’t have any formalized timeline. People are using gopls now, but it still doesn’t have feature parity with available tools / language servers. We will be sure to send out an update when we are confident that gopls is fully ready.

Is there a plan for how this might be done? I haven’t seen any discussion of it. If @typingduck has lost enthusiasm, I am happy to dig into this.

gopls will definitely grow these kinds of features, and if you want to try contributing it would be appreciated. The right first step is to implement find references, and then use that functionality to support renames. We have no plans at this point to fix the gorename tool itself, we think that focusing our efforts on improving gopls produces a better overall experience for the community, especially as we start exposing all of its functionality on the command line interface.

Just noting for those following along that @ianthehat has linked this issue to the tracking umbrella issue of https://github.com/golang/go/issues/24661

Closing this now as gopls now supports rename. If anyone has issues with gopls renaming, please feel free to open new issues against gopls.

Thanks @myitcv.

I just wanted to double check before starting that nobody else is working on this. It sounds like that’s a ‘no’ (having no prior experience on go tools I’m sure it will take me a few days longer to get up to speed than someone with experience).

I will start looking into it, but might wait until the next tools call before starting in earnest just to make sure I’m not stepping on someone else’s existing plans.

One more datapoint: I use emacs and the go-rename package, that uses the gorename tool.

Would love to see this fixed, almost to the point of trying it myself. But I have so little time in next month…

@stamblerre this helped immediately

Also, it may be worth updating to master for now (go get -u golang.org/x/tools/gopls@master

yeah that’s fair - I still develop my module-enabled project in gopath mode, but with gopls on for some features. gopls is soooo much faster and I’m really excited about where it’s headed, but I frequently have to revert to older tooling for certain features that haven’t made it to gopls yet.