LanguageServer crashing

[smabie]

So I'm having some issues with LanguageServer. I'm using emacs and actually having issues with both the version bundled with julia-lsp and the system one. I'm using julia 1.4.1. Here's the elisp code (from lsp-julia) that starts the server:

(defun lsp-julia--rls-command ()
  "The command to lauch the Julia Language Server."
  `(,lsp-julia-command
    ,@lsp-julia-flags
    ,(concat "-e using LanguageServer, Sockets, SymbolServer;"
             " server = LanguageServer.LanguageServerInstance("
             " stdin, stdout, false,"
             " \"" (lsp-julia--get-root) "\","
             " \"" (lsp-julia--get-depot-path) "\");"
             " server.runlinter = true;"
             " run(server);")))

lsp-julia-root is set to ~/.julia/environments/v1.4

lsp-julia-depot is set to ~/.julia/

The error I get is:

ERROR: MethodError: Cannot `convert` an object of type String to an object of type Function
Closest candidates are:
  convert(::Type{T}, !Matched::T) where T at essentials.jl:171
Stacktrace:
 [1] convert(::Type{Union{Nothing, Function}}, ::String) at ./some.jl:34
 [2] LanguageServer.JSONRPCEndpoints.JSONRPCEndpoint(::Base.PipeEndpoint, ::Base.PipeEndpoint, ::String) at /home/sturm/.julia/packages/LanguageServer/mpNvN/src/jsonrpcendpoint.jl:62
 [3] LanguageServerInstance(::Base.PipeEndpoint, ::Base.PipeEndpoint, ::Bool, ::String, ::String, ::Nothing) at /home/sturm/.julia/packages/LanguageServer/mpNvN/src/languageserverinstance.jl:62 (repeats 2 times)
 [4] top-level scope at none:1

If I instead use the bundled language server that comes with lsp-julia, I get a different error:

[ Info: Started symbol server
[ Info: JSON not stored on disc
ERROR: EOFError: read end of file

stderr from client process:

ERROR: LoadError: MethodError: no method matching is_stdlib(::Pkg.Types.Context, ::Base.UUID)
Stacktrace:
 [1] cache_package(::Pkg.Types.Context, ::Base.UUID, ::Dict{Any,Any}, ::String) at /home/sturm/.emacs.d/elpa/lsp-julia-20200511.1444/languageserver/SymbolServer/src/symbols.jl:215
 [2] cache_package(::Pkg.Types.Context, ::Base.UUID, ::Dict{Any,Any}) at /home/sturm/.emacs.d/elpa/lsp-julia-20200511.1444/languageserver/SymbolServer/src/symbols.jl:190
 [3] top-level scope at /home/sturm/.emacs.d/elpa/lsp-julia-20200511.1444/languageserver/SymbolServer/src/server.jl:39
in expression starting at /home/sturm/.emacs.d/elpa/lsp-julia-20200511.1444/languageserver/SymbolServer/src/server.jl:33

Stacktrace:
 [1] request(::SymbolServerProcess, ::Symbol, ::Array{String,1}) at /home/sturm/.emacs.d/elpa/lsp-julia-20200511.1444/languageserver/SymbolServer/src/SymbolServer.jl:68
 [2] cache_package(::SymbolServerProcess, ::Array{Base.UUID,1}) at /home/sturm/.emacs.d/elpa/lsp-julia-20200511.1444/languageserver/SymbolServer/src/SymbolServer.jl:235
 [3] cache_package at /home/sturm/.emacs.d/elpa/lsp-julia-20200511.1444/languageserver/SymbolServer/src/SymbolServer.jl:229 [inlined]
 [4] load_package_cache(::SymbolServerProcess, ::Base.UUID) at /home/sturm/.emacs.d/elpa/lsp-julia-20200511.1444/languageserver/SymbolServer/src/SymbolServer.jl:173
 [5] load_project_packages(::SymbolServerProcess) at /home/sturm/.emacs.d/elpa/lsp-julia-20200511.1444/languageserver/SymbolServer/src/SymbolServer.jl:95
 [6] getstore at /home/sturm/.emacs.d/elpa/lsp-julia-20200511.1444/languageserver/SymbolServer/src/SymbolServer.jl:101 [inlined]
 [7] run(::LanguageServerInstance) at /home/sturm/.emacs.d/elpa/lsp-julia-20200511.1444/languageserver/LanguageServer/src/languageserverinstance.jl:36
 [8] top-level scope at none:1
caused by [exception 1]
EOFError: read end of file
Stacktrace:
 [1] read(::Base.PipeEndpoint, ::Type{UInt8}) at ./stream.jl:868
 [2] deserialize at /build/julia/src/julia-1.4.1/usr/share/julia/stdlib/v1.4/Serialization/src/Serialization.jl:735 [inlined]
 [3] deserialize(::Base.Process) at /build/julia/src/julia-1.4.1/usr/share/julia/stdlib/v1.4/Serialization/src/Serialization.jl:722
 [4] request(::SymbolServerProcess, ::Symbol, ::Array{String,1}) at /home/sturm/.emacs.d/elpa/lsp-julia-20200511.1444/languageserver/SymbolServer/src/SymbolServer.jl:60
 [5] cache_package(::SymbolServerProcess, ::Array{Base.UUID,1}) at /home/sturm/.emacs.d/elpa/lsp-julia-20200511.1444/languageserver/SymbolServer/src/SymbolServer.jl:235
 [6] cache_package at /home/sturm/.emacs.d/elpa/lsp-julia-20200511.1444/languageserver/SymbolServer/src/SymbolServer.jl:229 [inlined]
 [7] load_package_cache(::SymbolServerProcess, ::Base.UUID) at /home/sturm/.emacs.d/elpa/lsp-julia-20200511.1444/languageserver/SymbolServer/src/SymbolServer.jl:173
 [8] load_project_packages(::SymbolServerProcess) at /home/sturm/.emacs.d/elpa/lsp-julia-20200511.1444/languageserver/SymbolServer/src/SymbolServer.jl:95
 [9] getstore at /home/sturm/.emacs.d/elpa/lsp-julia-20200511.1444/languageserver/SymbolServer/src/SymbolServer.jl:101 [inlined]
 [10] run(::LanguageServerInstance) at /home/sturm/.emacs.d/elpa/lsp-julia-20200511.1444/languageserver/LanguageServer/src/languageserverinstance.jl:36
 [11] top-level scope at none:1

Process julia-ls stderr finished

Does anyone know what the problem is? Thanks!

[smabie]

I'm receiving the same (second) error with Julia 1.3.1. I tried the language server bundled with lsp-julia and it finally worked.

[bstaletic]

Same traceback with Julia 1.4.2. I have just had a user report this problem.

[yuntan]

v3.1.0 (with coc.nvim) still crashing with same traceback. I'm using julia v1.4.0.

[smabie]

So is LSP totally broken for recent Julia versions? As in, does not work at all for any client?

[bstaletic]

Well, it crashes as soon as you attempt completion at the very least.

[smabie]

Shouldn't this be mentioned on the README.md? That this project doesn't work at all right now? Like this issue should be affecting everyone who uses Julia, right? Why is there so little attention on this right now?

[bstaletic]

#688

[yuntan]

I may found what wrong. The call siguniture of LanguageServerInstance should be (pipe_in, pipe_out, env_path::string). The code below for example.

(concat "-e using LanguageServer, Sockets, SymbolServer;"
             " server = LanguageServer.LanguageServerInstance("
             " stdin, stdout,"
             " \"" (lsp-julia--get-root) "\","
             " \"" (lsp-julia--get-depot-path) "\");"
             " server.runlinter = true;"
             " run(server);")

[davidanthoff]

Just to be clear, this package works very successfully for thousands of users every day as part of the VS Code extension.

I don't know much about other editors, so can't really help much with that, I'm afraid.

[non-Jedi]

The language server bundled with lsp-julia is not compatible with Julia 1.4+. Meanwhile, the latest version of languageserver.jl requires a different calling convention (thus the major version increment); see the docstring for LanguageServerInstance. I believe the maintainer of lsp-julia has a branch at https://github.com/gdkrmr/lsp-julia which uses the proper calling convention.

@davidanthoff I'm going to start using the "client-bug" tag for issues like this if you don't object?

[davidanthoff]

Yes, a client-bug label makes sense. I think we might also have an upstream already, which I used for things that aren't our fault?

[puremourning]

Just to be clear, this package works very successfully for thousands of users every day as part of the VS Code extension.

Are you saying that you are unable or unwilling to support usage anywhere else ?

Meanwhile, the latest version of languageserver.jl requires a different calling convention (thus the major version increment); see the docstring for LanguageServerInstance

We are using the this code to start the server based on what's in your README to start the LS; does that need to be updated ?

Out of curiosity, would it be possible to include a wrapper which starts the language server so that each client doesn't have to write this code ?

[non-Jedi]

We are using the this code to start the server based on what's in your README to start the LS; does that need to be updated ?

Check the README again. In major version 3 of LanguageServer.jl, the debug parameter has been dropped.

Out of curiosity, would it be possible to include a wrapper which starts the language server so that each client doesn't have to write this code ?

There's a bash script in the contrib directory, but it needs a bit of love.

What would a wrapper ideally need to look like to be useful to you? Obviously bash isn't generally available on Windows; is that a target for y'all? Maybe something like #695? Just a julia script that could be called with e.g. julia --project=/path/to/languageserver wrapperscript.jl /path/to/project/languageserver/is/running/on?

[ZacLN]

Are you saying that you are unable or unwilling to support usage anywhere else ?

Not at all, I think this was in direct response to the statement that this package doesn't work at all, which is demonstrably false. We're keen to support as many clients as possible but as you can imagine it is slightly challenging to support everything, across multiple versions of Julia.

We're trying but aren't there yet.

[puremourning]

What would a wrapper ideally need to look like

A binary maybe? Isn't julia a compiled language ? Forgive my ignorance.

Just a julia script that could be called with e.g. julia --project=/path/to/languageserver wrapperscript.jl /path/to/project/languageserver/is/running/on?

Yeah that would be great too - just some interface that is independent (mostly) of the underlying implementation, and makes it easy for users to configure "generic" LSP clients to just start the server.

TBH i feel like the project path should come from the LSP initialise, not the command line though.

#695

Yeah that looks useful. Perhaps publish the binaries as GitHub releases for example.

Not at all, I think this was in direct response to the statement that this package doesn't work at all, which is demonstrably false.

Sure understood, i can't condone that sort of claim either ;)

[non-Jedi]

Julia is kind of a compiled language but it can't usually produce a self-contained binary. We can sometimes contort it to make it so which is what #695 is doing, but that isn't well-tested or integrated for LanguageServer.jl.

TBH i feel like the project path should come from the LSP initialise, not the command line though.

See #748.

@ZacLN eglot-jl has a fairly minimal wrapper script. Do you think it makes sense to have that in the contrib directory in addition to bundling it with eglot-jl (I want to keep distributing it with eglot-jl so that the emacs package controls the LanguageServer.jl installation rather than having to be pointed to it)?