linkedProjects: support using different cargo configurations / targets

[ruabmbua]

I am having some difficulties with the linkedProjects feature of RA. Let me explain, what I am
trying to do.

My code base is structured like this:

.
├── Cargo.toml
├── cross
│  ├── Cargo.toml
│  ├── kernel
│  └── target-specs
├── libs
│  ├── allocator
│  └── noheap
└── xtask
   ├── Cargo.toml
   └── src

Note, that the top level Cargo.toml and the cross/Cargo.toml are separate workspaces.

To support that project layout, I use the following settings.json (for vscode):

{
    "rust-analyzer.cargo.target": "riscv64imac-unknown-none-elf",
    "rust-analyzer.linkedProjects": [
        "Cargo.toml",
        "cross/Cargo.toml",
    ]
}

I use two separate workspaces, because I want to build code for two targets at the same time.

The top level workspace is build by default for the host machine target. It contains a custom xtask crate,
which functions as a cargo-wrapper, which is used to execute some external tools (essentially for
post processing build artifacts from the cross/ workspace.
There is also a libs/ folder, containing code shared among the cross/ and root workspaces.

The cross/ workspace is by default cross compiled to a different architecture (RISC-V, and arm
bare-metal targets).

Unfortunately, rust-analyzer is not aware, that it should process the two workspaces for different targets
and also different features. Putting a default target into the relevant .cargo/config files does not work.

With the rust-analyzer vscode settings, I can only specify the target for all loaded projects at once with the
rust-analyzer.cargo.target config.

Is it possible, to specify the used cargo target and features for every linked workspace separately?
If not, should this feature be added? Right now, the RA project model is already very flexible (as I understand),
so supporting this may be too difficult.

[matklad]

Oh wow, that's quite a hole in the design indeed.... We need to think how to fix this. Some considirations:

• LSP use per-resource config
• which would conflict with rust-analyzer.toml, should we add that
• we need to keep common case simple and complex case possible
• this makes project explorer GUI , a-la cargo toolbar in IntelliJ, more important.

[ruabmbua]

This kind of project setup might become more commonly used, there was a blog post from ferrous systems (I think @japaric): https://ferrous-systems.com/blog/test-embedded-app/

I might be able to look into this issue myself sometime soon-ish. Of course, we need to come up with ab easy-but-flexible solution,
which is also not breaking current configurations.

[luojia65]

When writing embedded or operating system kernel, this feature might be more widely used.

[huntc]

Any further thinking on this? I could try a PR with some guidance. Thanks.

[crawford]

By default, could rust-analyzer build each of the targets specified in the cargo configuration? I believe that might also address #2142.

[fzn0x]

In my case rust-analyzer was only working on one folder, is it related?

[nasso]

this feature would be very useful when working in a workspace in which some crates target web assembly. right now, this (with #10021) makes RA unusable in this situation

[lylythechosenone]

Bump this, I'm in this situation myself.

@matklad are you on this?

[ultimaweapon]

I also having the same issue. My situation is I need to build a x86 Windows DLL that depend on x64 driver. I can't target the DLL to x64 due to it need to be loaded by x86 application.