Rename stuck with 100% CPU utilization

[inliquid]

VS Code: 1.33.1
vscode-go: 0.10.1-beta.1

Rename task took around 5 min with 100% CPU utilization with a result:

Rename failed

[ramya-rao-a]

We don't have much control over the performance of the gorename tool other than when to call it, when to kill it, what parameters to send to it when calling it.

Does this happen only when using Go modules?
Since gorename doesn't support modules, I can push a change to not rename at all when using modules.

[inliquid]

What? I use modules since the very beginning GO111MODULE=on. It does pretty well but sometimes it's like this. I don't think that waiting for 5 minutes for some command line utility is well-thought and "ideal" behavior that doesn't need any improvement.

Yes please disable gorename so I will finally switch to Goland and stop wasting time on this non-sense.

[ramya-rao-a]

I don't think that waiting for 5 minutes for some command line utility is well-thought and "ideal" behavior that doesn't need any improvement.

Depending on command line tools for various language features for Go is what most editors (VS Code, Sublime, Atom, vim, emacs) have done from the very beginning. This has served us very well over several years. Lately, with the introduction of Go modules, most of the tools in the Go tools eco system have been disrupted. Take a look at golang/go#24661 to get an idea of this disruption.

We will eventually all move to using language servers such that a single tool serves multiple language feature requests and can be the one stop shop for all language needs.

Until then, the one improvement that we can consider is adding a timeout for all situations where we use command line utilities like gorename. #2348 tracks exactly this and we have a PR #2372 in progress for this.

I use modules since the very beginning GO111MODULE=on. It does pretty well but sometimes it's like this.

Yes please disable gorename

Since it works some of the times, instead of disabling it altogether, we will add a timeout for this

I will finally switch to Goland and stop wasting time on this non-sense.

That is absolutely your choice.

Closing this issue as we have #2348 that tracks the current solution to the problem in this issue.
Please subscribe to that issue if you want to be notified of when the fix is made.

[inliquid]

This has served us very well over several years. Lately, with the introduction of Go modules, most of the tools in the Go tools eco system have been disrupted. Take a look at golang/go#24661 to get an idea of this disruption.

Go Modules have been introduced in September 2018 with the intention to make them a default thing for the entire Ecosystem. Now it's April 2019. What am I missing?

And vgo was introduced even earlier.

[ramya-rao-a]

What am I missing?

What you are missing is captured in golang/go#24661 as well as in golang/go#27571

Let me re-iterate. Language support for Go in editors have always been dependent on community Go tools like in this case gorename. The exceptions for this is an IDE like Goland which has proprietary (and non open source) code and team of multiple people working on it full time. All other editors have been backed by open source projects which dependent on the Go tools mentioned above.

With gopls the language server from Google getting traction, we will be able to stop depending on the multiple tool set and use just the language server very soon.