Tracking issue: multiple targets/workspaces/packages, etc.

[nrc]

In many situations there is not just one primary crate - workspaces and packages are I think examples of this, basically. Another common one is where there is both a lib and bin (where cargo users would use --lib or --bin to filter builds). A related issue is where the primary crate is actually just a thin wrapper around a more interesting dep crate. There is also the case where a user wants to edit files in both the primary crate and a dep. The RLS doesn't really handle any of these scenarios very well.

Currently the only thing we can do about this is effectively set cargo check --lib by setting the build_lib option in rls.toml. We should expand the config file so we can set other filters and set a dep to be the primary crate for a project.

More long term we should:

• handle multiple active crates (this will require keeping files from more than one crate in the VFS and being smarter about how and what we rebuild)
• be able to infer sensible defaults for rls.toml options from the Cargo.toml
• offer UI for setting options for a project

cc #102

[sophiajt]

Diesel is an example of this style

[matklad]

being smarter about how and what we rebuild

Sorry for pushing this once again, but I really think that true rebuilding is not an option here. You should be able to have crates A and B, with B depending on A and with both crates modified (and not really able to compile fully). If the RLS wants to call into the compiler rustc should be able to handle more than one crate at once. That is, it should use A source code and not .rlib when compiling B.

I hope that this is included in the long-term plan for RLS/compiler integration. I totally understand why this restriction makes sense at the current stage :)

[bwasty]

Two cases I've run into that were not explicitly mentioned:

• examples in /src/example (cargo run --example <name>)
• multiple binaries in in /src/bin (cargo run --bin <name>)

For these it would be nice to not have to configure anything. Maybe the RLS could infer the settings from the directory path?

[Xanewok]

I probably should've posted more information on the work done for the workspaces here, sorry. More info can be also found over at #263.

Currently the new workspace mode can be enabled via "rust.workspace_mode" (needs "rust.unstable_features").
The default is to run something along the lines of cargo check --all. Additionally, in it, "rust.analyze_package" can be further specified to limit analysis only to a single package (as if -p <name> was used instead of --all).

Reporting diagnostics and lazy (i.e. not full) package rebuild should work now.
However, analysis data still requires more work (rust-dev-tools/rls-analysis#93).
As of now, the data may not be properly linked (the reloaded data seems to be valid only when used inside only last built package).

[nrc]

Status update. We're currently waiting on rust-dev-tools/rls-analysis#106 which is blocked on a Rust PR. Once that lands, we're basically done with our plan for workspaces (thanks @Xanewok !). Having both a lib and a bin (or multiple bins) should also be solved as part of that work, and build scripts (AIUI).

We can support any one of multiple targets using an option and there is work in progress (I think) for arbitrary Cargo features.

So, remaining work that I'm aware of:

• testing and debugging the various configurations (rustc and Servo would be good stress tests, but I think there might be other issues working with their build systems and general size/complexity. I don't think we need to handle such projects just yet, but things like Diesel and WebRender should be fine. Build scripts are probably an area we should test in detail).
• make sure that the options we offer are coherent, well-documented, cover most possibilities, and have sensible defaults.
• stabilise workspace support
• optimise (and hopefully remove) the distinction between single crate and workspace modes
• optimise the end to end compilation, i.e., can we make changes to Cargo or rustc that can make the RLS cleaner or faster?
• (related) support the RLS in tests and examples directories.