golang + tramp, Flycheck checker go-build explodes

[fxfactorial]

Thank you for the bug report

• I am using the latest version of lsp-mode related packages.
• I checked FAQ and Troubleshooting sections
• You may also try reproduce the issue using clean environment using the following command: M-x lsp-start-plain

Bug description

Trying to get golang coding over tramp working and running into issues

in Messages , I have

LSP :: Connected to [gopls-remote:3211248/starting].
LSP :: gopls-remote has exited (exited abnormally with code 2)
Suspicious state from syntax checker go-build: Flycheck checker go-build returned 1, but its output contained no errors: go: go.mod file not found in current directory or any parent directory; see 'go help modules'

Try installing a more recent version of go-build, and please open a bug report if the issue persists in the latest release.  Thanks!

which seems to imply that gopls-remote is working correctly but then it explodes on a missing go.mod

the remote machine's .bashrc uses gimme for golang,

export GOPATH="$HOME/go"
export PATH="$GOPATH/bin:$PATH:$HOME/bin:/usr/local/cuda-11.4/bin"
export GO111MODULE=on

source ~/.gimme/envs/go1.17.5.env 2>/dev/null

and my ( i think only relevant parts) of emacs init.el

(add-to-list 'tramp-remote-path "/home/mev/.gimme/versions/go1.17.5.linux.amd64/bin")
(add-to-list 'tramp-remote-path 'tramp-default-remote-path)
(add-to-list 'tramp-remote-path 'tramp-own-remote-path)
(require 'lsp-mode)
(lsp-register-client
 (make-lsp-client :new-connection (lsp-tramp-connection
                                   (lambda ()
				     (cons "gopls" lsp-gopls-server-args)))
                  :major-modes '(go-mode)
                  :priority 10
                  :server-id 'gopls-remote
                  :remote? t
                  ))

appreciate any insight, help

Steps to reproduce

wrote the config code used

Expected behavior

should not crash exit 2

Which Language Server did you use?

gopls with lsp

OS

Linux

Error callstack

No response

Anything else?

No response

[yyoncho]

the remote machine's .bashrc uses gimme for golang,

export GOPATH="$HOME/go"
export PATH="$GOPATH/bin:$PATH:$HOME/bin:/usr/local/cuda-11.4/bin"
export GO111MODULE=on

source ~/.gimme/envs/go1.17.5.env 2>/dev/null

I don't think that any of these is picked by tramp. If these are esential for starting gopls, create a wrapper script that sets them and starts gopls. Note that if the binary that you have provided to lsp-mode is crashing there is nothing lsp-mode can do.

[fxfactorial]

@yyoncho right, that's why i added

(add-to-list 'tramp-remote-path "/home/mev/.gimme/versions/go1.17.5.linux.amd64/bin")
(add-to-list 'tramp-remote-path 'tramp-default-remote-path)
(add-to-list 'tramp-remote-path 'tramp-own-remote-path)

and

LSP :: Connected to [gopls-remote:3211248/starting].

seemed to imply that the binary indeed started up

EDIT: I copied the gopls binary to under /usr/local/bin and /usr/bin, same error so i dont think its because the binary not seen and the lsp-log buffer does say

Command "gopls" is present on the path.

[yyoncho]

Check stderr which will be in /tmp on the remote machine. Also, you may try to start gopls in eshell buffer to check what the error is.

@yyoncho right, that's why i added

I meant that things like export GO111MODULE=on won't be in gopls env.

[fxfactorial]

thank you, checked /tmp and found the gopls-remote-n-stdeer, it always says

gopls: unmarshaling jsonrpc message: unexpected end of JSON input

[yyoncho]

Most likely this: #2375 . There are several attempts to fix this

[fxfactorial]

gotcha - so the input is too large wrt the time to complete available for the async read?

thank you for the quick replies

[yyoncho]

Tramp for some reason(unknown to me) converts \n in \r\n. The result is that the message end is confused and json parsing fails. There are PRs claiming to fix that. I haven't had the time to investigate and merge the fix(FTR on my side I am unable to hit the issue using docker images).