GoRename fails if there is some errors in code

[nothingelsematters7]

I try to rename some variable in my code when there is some errors in it.

After running :GoRename command my cursor is moved to first error in code and I cannot even understand what happened. There is any error in status line and Location List with errors is not opened.
Only after running :lopen I can view list of errors.

Variable is not renamed.

[shazow]

Same here, :GoRename stopped working at some point with no output generated. Not even in :lopen or :messages. I'm running neovim, if it matters.

Would be nice if it was easy to run the equivalent of gorename -v (verbose mode) to get a better idea of what's going wrong. Definitely need somekind of indicator of failure, at least.

[shazow]

Performing a poor man's bisect, seems failure output was working in d5a1dff but missing in ecd2a83, so somewhere between those two. :P

[shazow]

Doing a slightly wealthier man's bisect, seems it was semi-working in 0ee6e91 (some errors, probably a broken commit), but 056a911 was the first commit where the output was missing altogether.

[shazow]

Looks like most (all?) commands' non-success output get eaten in the latest version. :GoTest timeout failure doesn't show up anywhere either.

[shazow]

Continuing the investigation (apologies for the comment trickle/barrage):

The problem is here:

vim-go/autoload/go/tool.vim

Line 50 in 056a911

if !empty(fatalerrors)

gorename produces failure messages like "gorename: can't find package containing ..." which is not considered an error by the regexp '^(fatal error:.*)$' so it gets swallowed.

I think a better approach would to only rely on the code of the exec? Or at least fall back on the original error string if ParseErrors fails to extract anything.

[shazow]

Ok I figured out what's going on and I think I understand how it's supposed to work based on the other commands. Sending a PR. :)