Something like this was reported by our internal users, but it's the first time I witness it myself. See attached video.

I was using the theiaide/theia-go image (https://hub.docker.com/r/theiaide/theia-go/), pulled fresh today. In it, I cloned the golang repo (https://github.com/golang/go.git) and noticed I could not open file src/bufio/bufio_test.go . However I am able to open other .go files in the same directory. The file itself looks fine; I can "cat" it successfully.

This may not consistently reproducable (it works for me using a different, internal docker image, that also has golang LS).

Here's the exception:

Uncaught (in promise) A resource provider for 'file:///home/theia/go/src/bufio/bufio_test.go' is not registered.
rejected @ opener-service.ts:6
Promise.then (async)
step @ opener-service.ts:6
fulfilled @ opener-service.ts:6
Promise.then (async)
step @ opener-service.ts:6
(anonymous) @ opener-service.ts:6
__awaiter @ opener-service.ts:6
open @ opener-service.ts:71
FileNavigatorModel.doOpenNode @ navigator-model.ts:32
TreeModel.openNode @ tree-model.ts:238
TreeWidget.handleDblClickEvent @ tree-widget.ts:280
ondblclick @ tree-widget.ts:131

In the responses to textDocument/codeLens and codeLens/resolve, go-language-server currently returns objects with unnecessary fields that are not specified in the Language Server Protocol. This is not a big problem per-se, because the extra JSON fields can be ignored by the consumers. However, they represent a significant amount of data.

In particular, each item in the CodeLens array that is returned as the response to textDocument/codeLens contains the text of the whole document. As an example, I opened the file ./src/net/http/h2_bundle.go from the Go source code [1]. Its size is 310K and contains about 440 functions, meaning we'll return about 440 code lenses. Just the duplicated in each entry that contains the document text will contribute for 136M of the response (the total response is bigger).

This is because the code returns blindly the internal vscode data structures. Because the CodeLens vscode data structure contains a reference to the text document, it is included every time the structure is serialized. Instead, we should generate structures that only contain the fields specified in the LSP.

[1] https://github.com/golang/go/blob/master/src/net/http/h2_bundle.go

Use the latest released version of vscode-languageclient. The protocol bits have been moved to a new package, vscode-languageserver-protocol, so add a dependency on it and adjust the code.

Signed-off-by: Simon Marchi [email protected]

If the go binary is not available from the PATH, the server outputs this error message.

server --> client: b'{"jsonrpc":"2.0","method":"window/logMessage","params":{"type":1,"message":"[lspserver] (node:17641) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 3): TypeError: \"file\" argument must be a non-empty string"}}' server --> client: b'{"jsonrpc":"2.0","method":"window/logMessage","params":{"type":1,"message":"[lspserver] (node:17641) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code."}}'

The TypeError comes from node's child_process.execFile when the vscode-go code tries to run the go binary, because goRuntimePath's value is undefined.

This patch makes updateGoPathGoRootFromConfig return a rejected promise with a meaningful error message when the go binary is not found, and then makes the server send an error message to the client including the error and backtrace. The result looks like this:

server --> client: b'{"jsonrpc":"2.0","method":"window/showMessage","params":{"type":1,"message":"Error: Cannot find \"go\" binary. Update PATH or GOROOT appropriately\n at Object.updateGoPathGoRootFromConfig (/home/emaisin/src/go-language-server/out/src/goInstallTools.js:280:31)\n at Object. (/home/emaisin/src/go-language-server/out/src-vscode-mock/activate.js:105:33)\n at Generator.next ()\n at /home/emaisin/src/go-language-server/out/src-vscode-mock/activate.js:13:71\n at new Promise ()\n at __awaiter (/home/emaisin/src/go-language-server/out/src-vscode-mock/activate.js:9:12)\n at Object.activate (/home/emaisin/src/go-language-server/out/src-vscode-mock/activate.js:34:12)\n at LspServer. (/home/emaisin/src/go-language-server/out/src-vscode-mock/lsp-server.js:93:31)\n at Generator.next ()\n at /home/emaisin/src/go-language-server/out/src-vscode-mock/lsp-server.js:13:71"}}'

It's not very readable as-is, but I suppose that when the client prints it in a log, the \n will be presented as real line breaks. But the important thing is that the info is there, so that one has a lead to start debugging.

There was another instance (in runTool) where the result of getGoRuntimePath was not checked, so it generated a similar unclear error.

Fixes #16

Signed-off-by: Simon Marchi [email protected]

On the LS, we don't have selection. Would be great if the client sent the selection as an argument with the commands that need it. A wrapper command on the client could be helpful.

A lot of valuable output goes into the output channel of the VSCode extension. We should implement something similar for Theia and then route the outputChannel there. Maybe related to https://github.com/theia-ide/theia/issues/786

add go get for fillstruct (as listed on https://github.com/theia-ide/go-language-server/blob/master/src/goInstallTools.ts#L42 )

Change-Id: I61b01918501cc034858e6046d51b17ad9bbdf9ea Signed-off-by: nickboldt [email protected]

When a Command LSP record is output in a codeLens/resolve response, it contains these fields, which are not specified by the LSP:

"uriRangeOrPosition": { "start": { "character": 10, "line": 32 }, "end": { "character": 18, "line": 32 } }, "rangeOrUri": { "scheme": "file", "fsPath": "/home/emaisin/src/ls-interact/go-test/test.go", "external": "file:///home/emaisin/src/ls-interact/go-test/test.go", "path": "/home/emaisin/src/ls-interact/go-test/test.go", "$mid": 1 }

This patch makes the server output only the fields that are specified by the LSP. I made a standalone function to convert from a vscode Command to an LSP Command, because we might have to re-use it in other responses that contain commands.

Signed-off-by: Simon Marchi [email protected]

When trying to use the server, I got this error:

server --> client: b'{"jsonrpc":"2.0","method":"window/logMessage","params":{"type":1,"message":"[lspserver] (node:17641) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 3): TypeError: \\"file\\" argument must be a non-empty string"}}'
server --> client: b'{"jsonrpc":"2.0","method":"window/logMessage","params":{"type":1,"message":"[lspserver] (node:17641) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code."}}'

and the server wouldn't reply anything. After some debugging, I found that it was because it didn't find the go binary. The rejected promise should be handled to avoid that warning, and a better error message should be given to the user to indicate what to fix.

Code lens works fine apart from opening the references:

The server composes a set of arguments of type URI, Position and Location[] for the editor.action.showReferences command (in goReferencesCodelens#resolveCodeLens). These are sent to the client, as such converted to plain JSON objects. The client, when trying to execute the command, validates the args to be instance of URI, IPosition and Array, which fails as they are plain JSON objects.

One solution could be to register a separate command in the theia-go-extension that is called instead and does the conversion.

Currently if a clientProcessId is provided, the program prints and error to stdio (which will disrupt connections made via stdio).

Signed-off-by: Casey Flynn [email protected]

This situation can happen if you hold ctrl down and hover some words in comments with your cursor.

client --> server: {"id": 124, "jsonrpc": "2.0", "method": "textDocument/definition", "params": {"textDocument": {"uri": "file:///home/emaisin/src/ls-interact/go-test/test.go"}, "position": {"character": 46, "line": 12}}}
server --> client: {"jsonrpc":"2.0","id":124,"error":{"code":-32600,"message":"Command failed: /home/emaisin/gopath/bin/godef -t -i -f /home/emaisin/src/ls-interact/go-test/test.go -o 334\ngodef: no identifier found\n","data":"Command failed: /home/emaisin/gopath/bin/godef -t -i -f /home/emaisin/src/ls-interact/go-test/test.go -o 334\ngodef: no identifier found\n"}}

In Theia, this results in an annoying error popup. If you move all over the comments with your cursor while holding ctrl, you'll get many error popups.

It can be reproduced when using this code there (test.go): https://github.com/simark/ls-interact/tree/master/go-test, and hovering the word "that" on line 13.

Currently, we only use the command title to present commands to the user. The command descriptions are sometimes much more meaningful. Do we have a way to map them to LSP or at least Theia?

The VSCode extension executes VSCode commands in a couple of places. We should introduce new LSP requests/notifications for these or get rid of the command calls.