search

fatih / vim-go

Go development plugin for Vim
https://www.patreon.com/bhcleek
Other
16k stars 1.45k forks source link

GoRename fails if there is some errors in code #664

Closed nothingelsematters7 closed 8 years ago

nothingelsematters7 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

shazow commented 8 years ago

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

shazow commented 8 years ago

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

shazow commented 8 years ago

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

The problem is here: https://github.com/fatih/vim-go/blob/056a91144b8d8f7407f3af5cffdc13db504ebfb1/autoload/go/tool.vim#L50

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 commented 8 years ago

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. :)