fix: LSP CodeAction sometimes results in "error: column is beyond end of line" #817
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In #801 we saw a report of "error: column is beyond end of line" coming back from the LSP.
This turned out to be hard to reproduce without the specific set of files, and also because different editors, extensions, and versions of gopls interact differently with the LSP.
However, investigating the issue, I spotted that
CodeAction
doesn't do any rewriting of the templ source positions to the target Go positions. This means that sometimes, the templ source position would indeed be past the end of a Go source code line, but the behaviour would be hard to reproduce, since it would require the specificCodeAction
to have been executed, and it may require a specific version ofgopls
etc.I use Neovim where to run a code action I have to press
space
followed byc
anda
. However, in VS Code, it's likely that some extensions are calling this LSP feature regularly - maybe even every time a cursor moves position, or a file is edited, meaning that those users are much more likely to spot this issue.It looks to me like
CodeAction
can't ever have worked up until this point, since the rewrites weren't properly done, and also, becausegopls
ignores actions on generated code, based on magic comments in the file.This PR does a few things:
gopls
error doesn't happen.CodeAction
results fromgopls
, since we haven't got tests for the behaviour and can't guarantee it.Code generated
comment, but doesn't enable it yet, because it may introduce other defects and we need to do more testing before that gets switched on.I think that this will fix #801