RLS "textDocument/definition" always returns `[]` if invoked on `.cargo` cache entries

[norru]

I have imported the whole of .cargo as a project in Eclipse Corrosion - textDocument/hover seems to work for the entries but textDocument/definition doesn't (so Ctrl+click for quick navigation doesn't work)

LSP4E to org.eclipse.corrosion.rls:{"jsonrpc":"2.0","id":"229","method":"textDocument/definition","params":{"textDocument":{"uri":"file:///home/nico/.cargo/registry/src/git.colasdn.top-1ecc6299db9ec823/log4rs-0.8.0/src/config.rs"},"uri":"file:///home/nico/.cargo/registry/src/git.colasdn.top-1ecc6299db9ec823/log4rs-0.8.0/src/config.rs","position":{"line":286,"character":17}}}
org.eclipse.corrosion.rls to LSP4E:{"jsonrpc":"2.0","id":229,"result":[]}
LSP4E to org.eclipse.corrosion.rls:Content-Length: 327


LSP4E to org.eclipse.corrosion.rls:{"jsonrpc":"2.0","id":"230","method":"textDocument/hover","params":{"textDocument":{"uri":"file:///home/nico/.cargo/registry/src/git.colasdn.top-1ecc6299db9ec823/log4rs-0.8.0/src/config.rs"},"uri":"file:///home/nico/.cargo/registry/src/git.colasdn.top-1ecc6299db9ec823/log4rs-0.8.0/src/config.rs","position":{"line":286,"character":17}}}
org.eclipse.corrosion.rls to LSP4E:{"jsonrpc":"2.0","id":230,"result":{"contents":[{"language":"rust","value":"appenders: Vec<Appender>"}]}}

[alexheretic]

Most rls functionality works from compiler analyses. So in general if you can't cargo check it you can't rls it.

Racer is a notable exception not using the compiler at all, so functionality that uses racer may continue to work in directories that can't be compiled.

[norru]

So, the workaround is to switch to an IDE which doesn't rely on RLS, such as CLion?

[norru]

Or, would it be possible to add options so the RLS reads other directories? Browsing through libraries is a very common operation. IIRC RustDT (based on Racer) could do this, at least partially.

[norru]

@alexheretic Why does textDocument/hover work though? Is it not implemented the same way as textDocument/definition?

[alexheretic]

Or, would it be possible to add options so the RLS reads other directories? Browsing through libraries is a very common operation. IIRC RustDT (based on Racer) could do this, at least partially.

It would be cool for rls to handle 1 or more child projects without a workspace. Perhaps a rls-manager wrapper that starts up rls processes for each folder. But it's not a simple thing and maybe is a clientside concern.

Why does textDocument/hover work though? Is it not implemented the same way as textDocument/definition?

Looking at the source textDocument/definition does not use racer, it has a fallback to racer which is disabled by default. textDocument/hover also falls back to using racer, but this is enabled by default, more precisely it uses the racer_completion config which is enabled by default.

[norru]

How does one enable Racer for the textDocument/definition fallback?

[alexheretic]

You can enable the definition racer fallback with goto_def_racer_fallback = true, however you're client does config. See https://github.com/rust-lang/rls/blob/master/src/config.rs#L130

I'd guess this is soft-deprecated as we don't document this config at the moment.

[norru]

This configuration option is not available in Corrosion. We need a way to set this option in RLS.

@mickaelistria @alexheretic @nrc

We are going round in circles here. We need to solve the following paradox:

• Corrosion will not implement this functionality because its developers think it's a RLS specific option.

Corrosion builds on LSP4E, which has no plan to support language server-specific settings and only settings which are available in EVERY language server will be supported by LSP4E

• RLS will not implement this functionality because its developers think it's a Corrosion-specfic feature.

RLS does not provide any means of configuration outside of the client interface. This means than every client has to separately build a configuration interface and try to keep up with the configuration settings, which requires a lot of (usually scarce) time and effort.

This has been the case for many months. As a result there are many issues open in Corrosion caused by the root problem: users are still unable to change settings in Eclipse.

Would you gentlemen please agree on a solution?

[alexheretic]

My take is that the current config situation is quite reasonable, rls provides the best general purpose default setup without config but also allows configuration from the client via the LSP.

A language server client in general is a whole load of code common to all clients and a little specialised to a particular server. For example ide-rust mostly relies on atom-languageclient, but it also has some RLS specific stuff of it's own like config, toolchain management & window/progress handling. So it was possible here to have the LSP dealt with by a common library but allowing extension to deal with custom stuff too.

I personally didn't find the client config much effort at all. ide-rust just watches a root rls.toml file and sends whatever the contents is.

On the other hand if you don't implement any client config stuff, rls still works. Indeed it should work well.

To be clear, I'm not the guy that makes decisions for rls. You can totally ignore me. I just send in occasional patches to make the git log statistically more handsome. But why not accept that rls wants config sent from client and work from there?

• Would Allow enablement of plugins in InitializeParams.initializationOptions #1026 have helped? If so where is the pr? This would not be too hard to develop as far as I can see.
• Why not develop the client code to send config and see how bad it is?
• Or develop a tiny binary that starts rls as a child process forwarding over it's own stdin, but also watches for a rls.toml file sending workspace/didChangeConfiguration for changes. You could use that binary instead of rls directly and share it with any other client that wants similar functionality.
• Or send in a pr for an optional rls.toml watching mode rls --watch-rls-toml.

[norru]

But why not accept that rls wants config sent from client and work from there?

I think this is the whole point - again I summon @mickaelistria :)

What happens when an unstoppable force meets an immovable object?

The clients could say "why not accept that you have to configure your language server using language server settings and move from there?", which may be not far from the truth in LSP4E which has to handle language servers in a generic way and not just RLS, and definitely the LSP4E development team doesn't appear to have time and resources to take on this task.

I would look into it myself but I have little spare time and can use it to either write Rust code or write Java code which allows me to edit Rust code. My priority is to write Rust code. Writing Java code to fix the ways Rust code is edited would not leave me with enough time to write Rust code, thus defeating the purpose.

[norru]

Or develop a tiny binary that starts rls as a child process forwarding over it's own stdin, but also watches for a rls.toml file sending workspace/didChangeConfiguration for changes. You could use that binary instead of rls directly and share it with any other client that wants similar functionality.

Looks like a "S.E.P." solution.

This will produce another fiddly moving part which has to comply not with one but with two interfaces (and keep track of changes in both), and needs to be maintained, documented, distributed as a rustup component etc.

ide-rust just watches a root rls.toml file and sends whatever the contents is.

This would be a good compromise (I think we floated this idea in the Corrosion discussion threads). Still the question remains: if this is so common an option, why does every client has to reinvent it? Wouldn't it be more practical for everybody to just have the RLS load its own config from somewhere handy?

Or send in a pr for an optional rls.toml watching mode rls --watch-rls-toml.

@mickaelistria - would Corrosion support optional command line parameters in the rls startup? Would an env var bypass the problem instead (at the cost of usability)?

@alexheretic for all my purposes, #1047 would do perfectly. I can live with RLS only reading its config at startup even if it means I have to restart it when I need a configuration change. I have to restart it many times anyway given it often gets stuck or silently stops working (or is it LSP4E?).

[alexheretic]

if this is so common an option, why do every client has to reinvent it?

Well no-one else has asked for it, so it's not common. Even I wouldn't use it in ide-rust, as clientside config gives clients more flexibility. (I use it so I can set global config for clippy_preference & all_targets in ide-rust settings, which I think is nice to have) Afaik ide-rust is the only client using rls.toml, and I may migrate away once atom's own per-project configuration ideas stabilize.

[alexheretic]

@norru out of interest what has you wedded to eclipse anyway?