Enable/disabling a single Cargo Feature

[AS1100K]

This feature request is inspired form RustRover

https://www.jetbrains.com/help/rust/rust-cfg-support.html#enable-disable-feature

Although this functionality can be using Zed settings.json like:

{
  "lsp": {
    "rust-analyzer": {
      "initialization_options": {
        "cargo": {
          "features": ["feature_name_1", "feature_name_2"]
        }
      }
    }
  }
}

but if we have the ability to enable/disable some cargo features on the fly that would be amazing

[notpeter]

To be explicit, your request is for the ability to manipulate Cargo.toml features which change rust-analyzer behavior via checkbox?

I don't quite understand... is your actual request to ignore features specified in cargo.toml and allow some mechanism to implicitly reconfigure cargo features based on checkboxes overriding os/features next to cargo features?

Sorry to be pedantic, but what does it even mean to uncheck/check a cfg[os=windows] feature on macos? Does it mean to add an explicit feature initialization _options workspace setting? Or something implicit?

How do you envision these features being stored as state? Should they revert on workspace reload? Etc.

[AS1100K]

To be explicit, your request is for the ability to manipulate Cargo.toml features which change rust-analyzer behavior via checkbox?

Yes

I don't quite understand... is your actual request to ignore features specified in cargo.toml and allow some mechanism to implicitly reconfigure cargo features based on checkboxes overriding os/features next to cargo features?

When the project loads it should enable the default feature for rust-analyzer and if .zed/settings.json have already set the features then it should use those marking those features with tick. The checkbox would allow to enable/disable cargo features for rust analyzer

Sorry to be pedantic, but what does it even mean to uncheck/check a cfg[os=windows] feature on macos? Does it mean to add an explicit feature initialization _options workspace setting? Or something implicit?

Having this feature only makes sense for Cargo features and maybe only shown in Cargo.toml. Also, as you said uncheck/check a #[cfg(os=windows)] feature on macos doesn't make sense (IIRC rust-analyzer doesn't allow enable/disable them without changing the toolchain) and the user can override the default toolchain or there could be some dropdown somewhere to choose the toolchain for the rust-analyzer and project. IMO doing so shouldn't be allowed and my proposal for enable/disable is only for the Cargo features

How do you envision these features being stored as state? Should they revert on workspace reload? Etc.

The configuration shouldn't be stored and should reset on workspace reload. Maybe there could be a setting for user's to select the behavior to either store the state or not. IMO it shouldn't be stored

[yiffyrusdev]

I'd like to join the request and mention, that ability to turn features on/off on the fly would be amazing when working on SDKs, full stack web, CLI+library, etc.

The simplest use case, somewhat related to the AS1100K's, which I can introduce is full stack web - like leptos.
It is "isomorphic" framework, feature-flag driven - the same source code produces both server and client artifacts based on feature flags.
With a large enough project one will end up with a huge workspace, where every crate has mutually exclusive feature flags like client/server , ssr/hydrate.

In general it would be very convenient to not just have checkboxes in Cargo.toml, but to be able to configure feature flag sets for the RA and switch between them with a command.

e.g: for the mentioned use case, it would be pretty nice to configure two feature flag sets:

• "server": ["ssr", "rustls"]
• "client": ["hydrate"]

And then to be able to switch between them with a Zed command like workspace: features.