Build configuration pulldown to determine what code is grayed out based on active crate features

I have multiple application crates in my project that use several shared libraries with different sets of features.

Applications:

• app_client
• app_server
• etc.

Libraries:

• lib_net
• lib_sync
• lib_serialization
• etc.

Some of my common libraries have blocks of code that are intended just for the server or client. So I have blocks like #[cfg(feature = "enable_client")] and #[cfg(feature = "enable_server")] in lib_net, lib_sync, and so on. These features are somewhat mutually exclusive -- no application can be both server and client at the same time, and so some code doesn't make sense with both enabled. Because of this, I don't have these crates in a workspace in order to avoid feature unification. I have these crates all manually added to my rust-analyzer project using "rust-analyzer.linkedProjects".

The problem I'm currently having with this is that I can't control what code is grayed out. It seems somewhat arbitrary. Sometimes my client code will be grayed out if the server is the "main" application crate, and sometimes the opposite will happen if the client happens to be in the lead.

As a feature request, as an application developer I would like either one of two things:

a) The ability to set which application crate is the primary crate, and use its Cargo.toml and dependencies to determine which set of features is enabled for each of the other crates in the project, including for error highlighting (cargo check etc.).

or

b) Some sort of build configuration set up that allows me to set which features are enabled for code highlighting on a per-crate basis, including for error highlighting (cargo check etc.).

In both cases, I'd like to be able to quickly change between this with some sort of pulldown menu somewhere, similar to how it's done for C# or C++ when using the preprocessor in Visual Studio:

No files, tests, or entry points are named in the issue. Start by tracing rust-analyzer’s existing project configuration and Cargo feature handling, then clarify the intended design with maintainers; done would be a selectable per-crate feature configuration that affects code highlighting and error checking.