mirror of https://github.com/golang/go.git
d34cf35d93
When parse errors occur, go's parse package cannot recover nicely. gopls tried to compute folding ranges based on the partial info in this case, but returning partial folding range info confuses editors (vscode) and results in dropping previous folding range info from the region after the parse error location. This CL makes gopls not to return anything - so the editor can tell the result is not believable and ignore it. The ideal solution is to return a response explicitly surfacing this case, but currently LSP (3.16, as of today) does not have a way to describe this condition. See the discussion in https://github.com/microsoft/language-server-protocol/issues/1200. We also tried to make gopls return an error. While it worked nicely in VSCode, we are not sure about how other editors handle errors from foldingRange. So, instead, we just let gopls return an empty result - since foldingRange is already broken in this case, we hope it doesn't add a lot of noise to existing users. VSCode Go will check the response from the middleware. If the response is empty but the file is not empty, VSCode Go will ignore the response. (https://go-review.googlesource.com/c/vscode-go/+/299569) Updates golang/vscode-go#1224 Updates golang/go#41281 Change-Id: I917d6667508aabbca1906137eb5e21a97a6cfdaf Reviewed-on: https://go-review.googlesource.com/c/tools/+/291569 Trust: Hyang-Ah Hana Kim <hyangah@gmail.com> Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> gopls-CI: kokoro <noreply+kokoro@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org> |
||
|---|---|---|
| .. | ||
| a.go | ||
| a.go.golden | ||
| bad.go.golden | ||
| bad.go.in | ||