Multiple simultaneous target triples

[trevyn]

I have a project that compiles to both wasm32-unknown-unknown and the host triple, with heavy use of

#[cfg(target_arch = "wasm32")]

and

#[cfg(not(target_arch = "wasm32"))]

Right now, I can select one or the other target triple with rust-analyzer.cargo.target, but I miss errors and warnings from the other, and half of the code is dimmed out.

It would be cool to be able to show a combined view of errors and warnings from both triples at the same time, and no code would need to be dimmed.

[ruabmbua]

This is probably a duplicate of the following ticket: #8521

[kpreid]

I have a similar situation and would find this feature very useful. I can temporarily change the target triple, but because rust-analyzer is never aware of both variants of the code, it can never give me a complete list of references to an item that is used in the two target-specific parts, or check both at once, which would be useful when I am trying to change the interface between the generic code and the target-specific code.

(#8521 says it is specifically about two different workspaces, but I have only one workspace. Changing that is an idea I hadn't thought of, and I'm not yet sure whether it would improve the situation more than it complicates it, but regardless, rust-analyzer currently supports neither case.)

[trevyn]

For reference, I stumbled upon something vaguely resembling a workaround: I have an attribute proc-macro that just applies the appropriate cfg, which r-a is set not to expand. This then requires all relevant crates to be available as dependencies for the current target, but other than that does appear to ultimately result in the desired behavior of all code being processed by r-a.

EDIT: A similar result could probably be achieved by having a special cargo feature that r-a is configured to pass in, which disables the cfgs when checking. Again, this is only a partial workaround; my codebase happens to play well with this setup, others may not.

[nasso]

What makes this particularly hard to implement?

My naive approach to fix this problem would be to run cargo check multiple times with a different --target triple each time, and combine the results (eliminating duplicates). The list of targets to check could be manually specified through a user-specified array of triples (e.g. default/native/auto + wasm32-unknown-unknown).
Now this is clearly not ideal since a lot of the work is duplicated, but it could serve as a temporary solution before a more elaborate algorithm can be implemented (e.g. one that would ignore any #[cfg(...)] and "fork" the checking process only where necessary).

The current behaviour makes it really difficult to work on crates containing a lot of platform-specific code paths!

[DianaNites]

I just noticed this seems to be valid now

"rust-analyzer.check.targets": ["aarch64-apple-darwin", "x86_64-apple-darwin"]

Rust-analyzer › Check: Targets
Check for specific targets. Defaults to Rust-analyzer › Cargo: Target if empty.

Can be a single target, e.g. "x86_64-unknown-linux-gnu" or a list of targets, e.g. ["aarch64-apple-darwin", "x86_64-apple-darwin"].

Aliased as "checkOnSave.targets".

[nasso]

but is it possible to say "whatever is the default/native target + wasm32-unknown-unknown" ?

[DianaNites]

Does not appear so, no, but at least you probably arent changing your host target very often?

This doesn't work well in workspaces where some crates only compile on some targets but not others though

[nasso]

I work in a team; some of us are on different platforms and we would like to share the same editor configuration

though, yeah, in our workspace some crates only compile on some targets but not others, so we would need crate-specific configuration here anyway

[kpreid]

It occurs to me that it might be useful for cargo/rustc to have a special target string that means "the host's target triple, whatever that is". That would finish this problem for r-a and also be useful in build tools that have reason to deal with mixed cross-compiling and not.