Handle child projects without a cargo workspace

[alexheretic]

RLS runs like cargo check, it doesn't search through child projects looking for rust code. This means if a user opens a directory with child projects in their ide RLS probably won't work.

I raised this to discuss solutions framed by an accurate technical status quo. Related to #1196 #1198.

Example

.  <-- rls starts here
├── project-foo
│   ├── src
│   └── Cargo.toml
└── project-bar
    ├── src
    └── Cargo.toml

This won't work for the same reasons as cargo check

$ cargo check
error: could not find `Cargo.toml` in `/home/alex/foo` or any parent directory

A workaround that is nice for some cases is to create a Cargo.toml file in the root describing a cargo workspace. (See https://github.com/rust-lang/atom-ide-rust#multi-crate-projects). However, this isn't always desirable. Plus it would be great if this scenario somehow "just worked".

Ideas

These solutions come to mind, in order of RLS complexity:

Clients deal with it

Leave this up to the clients to solve, a client could feasibly detect child folders and start RLS in each. This is how cargo deals with this issue after all.

However, it's a bit tricky to ensure client logic doesn't conflict with cargo workspace logic. Also this means this issue will appear and have to be dealt with in each client.

Generate a virtual cargo workspace

Detect a no-manifest error and look for child projects. If we find some we can generate a virtual workspace manifest and run as if that existed.

However, I'm not sure if cargo can support a virtual manifest.

Manage child RLS processes

Detect a no-manifest error and instead run a proxy RLS that awaits more info (ie lsp requests). If these requests indicate a child project start a child process RLS to handle this and forward lsp traffic.

This could be a bit of a pain.

[mbaeten]

My involvement is not deep enough to comment on this qualifiedly, but I suppose it's more straight forward to let clients handle it, as they provide the lsp integration. Should be easier for the client to maintain n RLS instances with the correct subdirectories instead of RLS searching for them on it's own. Also, the client probably only has to start those RLS instances which are really needed.

[alexheretic]

I'd be tempted to try generating a virtual cargo workspace manifest. It seems like it would work quite well with fairly small effort. However, it looks like cargo workspace requirements mean the workspace Cargo.toml must be hierarchically above the child projects, so we can't shove a generated one in target/rls.

[alexheretic]

I've added https://github.com/alexheretic/rusttmp/tree/rls-1202 as an example of a multi-project directory that rls can't handle currently.

[alexheretic]

I've bandaged this issue in ide-rust with atom-ide-rust#118.