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.

[kawogi]

This is a recurring problem with lots of my projects with mixed targets. Especially workspaces containing embedded projects or targeting WASM.

A common situation is using the xtask pattern in a project that also targets WASM (see OP's message). I typically keep the xtask-crate within the same workspace, though. Whenever I globally switch Rust-Analyzer to wasm32-unknown-unknown, xtask will report all sorts of errors as it wasn't meant to compiled for this target. I cannot specify a target in .cargo/config, because xtask shall be supported on multiple platforms (Linux, Windows, etc.) but not wasm32-unknown-unknown.

Another situation is launchers. While some executables are ok on multiple targets (e.g. all linux*-flavors) others are only available to a single target (this is already covered). It's often not feasible to have a multi-target launcher - esp. with WASM: a single multi-threaded binary for a native system might have to split up for WASM to produce multiple workers.

I think it would already help to specify the target as default/native and pick whatever was configured as default for the build system (rustup toolchain).

Another option might be to blacklist build targets in .cargo/config and let RustAnalyzer chose from a list of configured fallback options.

Yet another idea would be to have profiles which act as an overlay to specify target overrides. This could be a configuration file (pseudo):

{
    "my_profile" : {
        "my_crate": "my-target-triple",
    },
    "wasm" : {
        "xtask": "default", // make sure that xtask is always built with the host's target triple
        // every other crate used the existing mechanism
    },
    "linux" : {
        "my_linux_launcher": "default",
        "my_windows_launcher": null, // ignore this crate
        "my_wasm_tools": null,
    },
}

On a second thought: Should this be approached by Cargo first? [https://github.com/rust-lang/cargo/issues/6179](Allow specifying a set of supported target platforms in Cargo.toml)

I'm not very experienced in tool configurations so please let me know if other workarounds exist.

[chunleng]

Hopefully this can be a temporary workaround for people who are waiting for a fix.
Using vim to explain as it is what I am using, feel free to think along the line in the tools that you are using.

I have twitched my local project config to launch 2 lsps for project that has workspaces with different target triple. 1 checks with -p=<proj> --target=<triple> and the other checks with --workspace --exclude=<proj>. To make autocompletion use the correct target triple, you will also need to pass in the correct cargo.target settings. Once you set the LSP in this way, the diagnostics should show the proper message for each target.

However,

• this workaround would not help with single project that needs multiple target triple
• Completion will show 2 suggestions for the modules and function that can be used in both target triple. (But at least it covers all the target triple of interest)

require("lspconfig").rust_analyzer.setup({
    settings = {
        ["rust-analyzer"] = {
            check = {
                overrideCommand = {"cargo", "check", "--quiet", "--workspace", "--exclude=proj-x", "--message-format=json"}
            },
        }
    }
})

require("lspconfig").rust_analyzer.setup({
    settings = {
        ["rust-analyzer"] = {
            check = {
                overrideCommand = {"cargo", "check", "--quiet", "-p=proj-x", "--message-format=json", "--target=wasm32-unknown-unknown"}
            },
            cargo = {
                target = "wasm32-unknown-unknown"
            }
        }
    }
})

But hopefully this is of help to anyone out there!