buildRustCrate does not support features with spaces

[danieldk]

Describe the bug
If a crate provides a feature with a space and it is enabled, the feature is incorrectly passed to the rustc command. Moreover CARGO_FEATURE_* is not set correctly.

To Reproduce
Steps to reproduce the behavior:

1. Add a feature with a space to:

   nixpkgs/pkgs/build-support/rust/build-rust-crate/test/default.nix

   Line 349 in cdc56bc

   features = [ "some-feature" "crate/another_feature" ];

2. nix-build -A buildRustCrateTests

Expected behavior
A successful build with the right features enabled.

Additional context
Background: #90193

Maintainer information:

# a list of nixpkgs attributes affected by the problem
attribute: buildRustCrateTests

[stale]

I marked this as stale due to inactivity. → More info

[danieldk]

I still care about this.

[stale]

I marked this as stale due to inactivity. → More info

[danieldk]

Still relevant.

[Fuuzetsu]

As of today/yesterday (Rust 1.60), this is a bigger problem because many features now look like dep:foo/bar and the colon breaks this code:

nixpkgs/pkgs/build-support/rust/build-rust-crate/configure-crate.nix

Line 179 in 2e2b664

export CARGO_FEATURE_$feature=1

Some issue as with a space really, need some sanitisation of feature names before they are exported as env vars.

[Fuuzetsu]

If a crate provides a feature with a space and it is enabled, the feature is incorrectly passed to the rustc command. Moreover CARGO_FEATURE_* is not set correctly.

In cargo code there's an envify function that it uses to set CARGO_FEATURE_*. All this function does is replace - with _ which is something we do already in nixpkgs.

Is a feature with a space in it a valid name to start with, according to cargo?

[pacak]

Is a feature with a space in it a valid name to start with, according to cargo?

No.

Feature names may include characters from the Unicode XID standard (which includes most letters), and additionally allows starting with _ or digits 0 through 9, and after the first character may also contain -, +, or ..

In practice it's even more restricted:

crates.io imposes additional constraints on feature name syntax that they must only be ASCII alphanumeric characters or _, -, or +.

[patka-123]

Hello @danieldk 👋

If I read the comment thread here correctly then features with spaces aren't valid. Does this mean that this issue is "resolved"? If so, would you be able to close this issue?

(I'm going through issues marked as stale to see what can be resolved. If this is still an issue then don't mind me).