emacs-lsp / lsp-mode

Emacs client/library for the Language Server Protocol
https://emacs-lsp.github.io/lsp-mode
GNU General Public License v3.0
4.76k stars 874 forks source link

golang + tramp, Flycheck checker go-build explodes #3342

Open fxfactorial opened 2 years ago

fxfactorial commented 2 years ago

Thank you for the bug report

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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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

gopls: unmarshaling jsonrpc message: unexpected end of JSON input
yyoncho commented 2 years ago

Most likely this: https://github.com/emacs-lsp/lsp-mode/issues/2375 . There are several attempts to fix this

fxfactorial commented 2 years ago

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

thank you for the quick replies

yyoncho commented 2 years ago

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).