Could the problem be because of the code here https://github.com/golang/tools/blob/054c06df410b0347e908c647ef441733aea4a8df/gopls/internal/golang/extract.go#L85

where both the assignment statement and the calculated LHS is sent as edits ?

Thanks for filing this bug. In this scenario it probably makes sense to skip emitting the expression that causes a syntax error, and leave the variable declarations as unused (especially since the extra expression does not qualify as a use anyway).

We are planning to look into improving our refactoring code actions in the near future, and all of the extract code actions suffer from a lack of support for customizing the names of new symbols. AFAICT LSP does not support snippets for codeactions, only for completions (see microsoft/language-server-protocol#592).

@suzmue You are correct. I think in other languages it is done by a custom action which consists of edits followed by a rename.

@suzmue I tried to improve the extract variable with the current features we have in LSP, Made the PR under golang/tools#482

Also as part of the CodeAction we can send a command which will run after the edits are applied. But we will only be able to rename one variable when there are multiple return values. So I felt that I should just check here before continuing on that path since I didn't feel that the effort to implement it brings much value. of course it might in majority of scenarios where the return values are value, error where we can prompt to rename the value variable. But then I would guess we need to suggest a better name for error variable, like err with a suffix if there is a name conflict.