Add --must-have-and-exclude-feature option.

[xStrom]

Summary

This new option allows for more precise testing of packages that support no_std.

The goal

I want to be able to properly test all packages that support no_std. The problem is tricky because I would like the command to be copy-pastable across 20 repositories and there's quite a bit of variation.

Old solution

cargo hack clippy
    --workspace
    --locked
    --target x86_64-unknown-none
    --optional-deps
    --each-feature
    --ignore-unknown-features
    --features libm
    --exclude-features ${{ env.FEATURES_DEPENDING_ON_STD }}

This kind of works, but has problems:

• It requires a per-workspace configuration variable to track features which depend on std.
• As packages grow in size, so do the odds that different packages in a workspace have an identically named feature, but only one of those actually requires std.
• The workspace can't easily have members which can't be compiled without std due to the use of --target x86_64-unknown-none. It is possible to overcome this, but it requires yet another per-workspace package exclusion configuration variable.

New solution in this PR

--must-have-and-exclude-feature <FEATURE>

  Require the specified feature to be present but excluded.

  Exclude the specified feature and all other features which depend on it.
  Exclude packages which don't have the specified feature.

  This is useful for doing no_std testing with --must-have-and-exclude-feature std.

With this new option, there is no longer a need for any configuration variables and the following command is universal:

cargo hack clippy
    --workspace
    --locked
    --target x86_64-unknown-none
    --optional-deps
    --each-feature
    --ignore-unknown-features
    --features libm
    --must-have-and-exclude-feature std

Now cargo-hack will make sure to only select packages which actually have a feature called std and it will also make sure to not enable any feature which would indirectly require std.

[xStrom]

Is there any hope to get this merged?

Being a volunteer open-source maintainer myself, I empathize with the lack of time and feel no entitlement to have this included.

However, this is a feature that our open-source organization would really benefit from. I would very much like to see it included as part of cargo-hack.