Rls: Not working if started in the `/`?

[dpc]

I was investigating an issue in https://github.com/ul/kak-lsp/ where for Rust some functionality wouldn't work.

Turned out that kak-lsp daemonize itself, it changes the cwd to /, and that's also the directory where rls will be started. Some functionality of rls still works, but "go to definition" and completions (both from racer?) do not. I am not sure if language server should have requirements in which working directory it was started or not, but I guess it would be better if it "just worked" in all circumstances.

I've filled a PR for kak-lsp too: https://github.com/ul/kak-lsp/pull/132

[norru]

Hi @Xanewok, we have encountered a similar problem in Corrosion.

RLS requires to be started from a cwd containing a Cargo.toml. What's the point of rootUri then?

The problem for us is that our LSP manager module (which handles all instances of all Language Servers) cannot assume anything about the cwd. This is because, by design, the LSP4E maintainers religiously follow the LSP spec and the LSP itself doesn't assume any dependency on the cwd.

According to the LSP spec this should be handled by setting up the rootUri rather than assuming a specific cwd. In theory, rls should start correctly, regardless of where it was started from.

https://github.com/eclipse/corrosion/issues/233

@mickaelistria @alexheretic FYI

[mickaelistria]

This is because, by design, the LSP4E maintainers religiously follow the LSP spec

Some context here is that LSP and language-servers are meant to annihilate most language-specific efforts to properly answer the N*M -> N+M integration goal. Language Servers that requires specific integration beyond what's is in the spec would require the client to setup more complexity (and time, workforce, technical debt...) to handle their oddities. As -like any project- we are limited in term of resource we can spend on the Language Servers integrations, we cannot afford implementing such oddities that are not in the spec and don't provide added-value over the state of arts.
We've integrated almost a dozen language servers in Eclipse IDE with LSP4E now, and RLS is the only one that would require to start from a specific cwd to work properly. This makes its integration more complex and more likely to fail. Sticking to existing concepts of the spec (like rootURI) would make things work without extra integration effort.

[Xanewok]

Just to be clear, this is a bug and we should definitely aim to support the rootUri-only use case. I'm not really sure yet why this doesn't work (I believe we initialize everything relative to the root URI), so will need to investigate why this breaks.

[norru]

LSP4E maintainers religiously follow the LSP spec

To clarify: "religiously" here is intended as "very rigorously and carefully" and has a positive connotation.

sure yet why this doesn't work

Perhaps there is a bit of confusion as @alexheretic and I were trying to reproduce the problem via rls --cli which might be behaving in a subtly different way?

Discussion here: https://github.com/rust-lang/rls/issues/1431. Caveat: I am not knowledgeable on LSP internals and integration so please bear with my silly questions - I come from the point of view of a "power" user (and occasional generalist maintainer) of Corrosion.