refactor: struct holding cargo cfgs settings #18885
Conversation
rustbot
added
the
S-waiting-on-review
crates/rust-analyzer/src/config.rs
Outdated
| (key, val) | ||
| }) | ||
| // we filter out anything with a None key | ||
| .filter(|(key, _)| key.is_some()) |
There was a problem hiding this comment.
You can avoid the unwrap and do this in one step using filter_map.
crates/rust-analyzer/src/config.rs
Outdated
| }, | ||
| cargo_cfgs: Vec<String> = { | ||
| vec!["debug_assertion".into(), "miri".into()] | ||
| } |
|
|
No it still doesn't. What you are using it for merely enables CFGs that are assumed by the ecosystem to be disjoint. It may improve your specific situation here but it doesn't change the fact that r-a cannot handle multiple targets in a crate at once. Either way thanks for the PR! You are correct that this being a map is incorrect given key-value cfgs can have overlapping keys. |
Yep, I fully agree with this statement. Yet I believe it provides a working alternative to opening several IDE with different r-a settings which becomes heavier when the number of targets increases. I actually hope it is gonna help others having the same issues as I have (being lazy enough to open several IDE instances to develop each of the targets). Thank you @lnicola for the review and @Veykril for the merging |
Change to
rust-analyzer.cargo.cfgsSettingThis PR replaces the current structure (a
HashMap) for therust-analyzer.cargo.cfgssetting with aVec<String>. The use of a vector seems more appropriate for the following reasons:cfgkeys can be used (currently impossible due to the use of aHashMap).HashMapis turned into a vector of (key, value) tuples, so it seems there is no benefit to using aHashMapto hold these settings.A beneficial side effect of this change is that
rust-analyzercan have partial support for multi-target analysis through this setting (see the following configuration example).New Format Example
{ "rust-analyzer.cargo.cfgs": [ "debug_assertion", "miri", "target_arch=x86_64", "target_arch=aarch64", ] }