Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/tools/gopls: returns incorrect text edits #33289

Closed
autozimu opened this issue Jul 26, 2019 · 4 comments
Closed

x/tools/gopls: returns incorrect text edits #33289

autozimu opened this issue Jul 26, 2019 · 4 comments

Comments

@autozimu
Copy link

@autozimu autozimu commented Jul 26, 2019

What version of Go are you using (go version)?

$ go version
go version go1.12.7 darwin/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/lijunfen/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/lijunfen/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/Cellar/go/1.12.7/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.12.7/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/sz/4srfsz3151xfrxz4t03y23hx7wl71v/T/go-build501432677=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

  1. Setup https://github.com/autozimu/LanguageClient-neovim
  2. Open a hello world go file.
  3. Set set nofixeol in vim/neovim.
  4. Call :call LanguageClient#textDocument_formatting_sync()

Note: this is not specific to this vim/neovim LSP client. It would affects many other LSP clients as the response is violating the protocol.

What did you expect to see?

gopls sends properly text edits.

What did you see instead?

gopls sends incorrect text edits that violate the protocol, in that no two text edits shall overlap.

This is originally reported as autozimu/LanguageClient-neovim#844 Please let me know if there is anything needed from me.

@gopherbot gopherbot added the gopls label Jul 26, 2019
@ianthehat

This comment has been minimized.

Copy link

@ianthehat ianthehat commented Jul 26, 2019

The response looks correct to me? Also I think it works in VSCode (the bug did not have the original source file to repro with so I was guessing from the returned edits)
Why do you think there is an overlap? It has two insertions at the end, but they are not overlapping, they are just insertions that should happen one after the other at the same location.
The spec is very explicit that this is allowed

All text edits ranges refer to positions in the original document. Text edits ranges must never overlap, that means no part of the original document must be manipulated by more than one edit. However, it is possible that multiple edits have the same start position: multiple inserts, or any number of inserts followed by a single remove or replace edit. If multiple inserts have the same position, the order in the array defines the order in which the inserted strings appear in the resulting text

Also note that a file without a \n a the end is not correctly formatted according to gofmt, so the formatting call will attempt to fix it for you.
cc @stamblerre

@stamblerre stamblerre changed the title gopls returns incorrect text edits x/tools/gopls: returns incorrect text edits Jul 26, 2019
@gopherbot gopherbot added this to the Unreleased milestone Jul 26, 2019
@autozimu

This comment has been minimized.

Copy link
Author

@autozimu autozimu commented Jul 30, 2019

I was believing there are overlaps because of the two edits targeting the same range. But that might fall into the However clause you pointed out.

Slightly off topic, VSCode itself works usually doesn't justify there isn't any issue. There are far too many implementations that are using VSCode as standard rather than the protocol itself, which makes plugins authors life harder.

Thanks for looking into this!

@autozimu autozimu closed this Jul 30, 2019
@ianthehat

This comment has been minimized.

Copy link

@ianthehat ianthehat commented Jul 30, 2019

Ok. Glad I could help.
I was not trying to imply that VSCode is always correct, just letting you know that I had attempted to reproduce it on the editor I normally use and was not just replying without checking, because it frustrates me when people do that to me.

@autozimu

This comment has been minimized.

Copy link
Author

@autozimu autozimu commented Jul 30, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.