crypto_kx: u32_backend / u64_backend feature is both enabled for x25519-dalek

[cr0sh]

Repro: Clone https://github.com/cr0sh/kx-test and run cargo check. Tested on ARM64 macOS and with (--target wasm32-wasi).

This only happens when a depending crate is a workspace member, not a standalone package. so it may be a cargo bug..?

cargo tree -i x25519-dalek -e features shows only u32_backend.

[cr0sh]

cargo check -v output:

...snip...
error[E0308]: mismatched types
   --> /Users/namjh/.cargo/registry/src/github.com-1ecc6299db9ec823/curve25519-dalek-3.2.1/src/backend/serial/u32/scalar.rs:373:40
    |
373 |         Scalar29::montgomery_mul(self, &constants::RR)
    |         ------------------------       ^^^^^^^^^^^^^^ expected struct `Scalar29`, found struct `Scalar52`
    |         |
    |         arguments to this function are incorrect
    |
    = note: expected reference `&Scalar29`
               found reference `&Scalar52`
note: associated function defined here
   --> /Users/namjh/.cargo/registry/src/github.com-1ecc6299db9ec823/curve25519-dalek-3.2.1/src/backend/serial/u32/scalar.rs:360:12
    |
360 |     pub fn montgomery_mul(a: &Scalar29, b: &Scalar29) -> Scalar29 {
    |            ^^^^^^^^^^^^^^               ------------

Some errors have detailed explanations: E0277, E0308, E0428, E0659.
For more information about an error, try `rustc --explain E0277`.
error: could not compile `curve25519-dalek` due to 1110 previous errors

Caused by:
  process didn't exit successfully: `rustc --crate-name curve25519_dalek /Users/namjh/.cargo/registry/src/github.com-1ecc6299db9ec823/curve25519-dalek-3.2.1/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata -C embed-bitcode=no -C split-debuginfo=unpacked -C debuginfo=2 --cfg 'feature="u32_backend"' --cfg 'feature="u64_backend"' -C metadata=f827783d50489c95 -C extra-filename=-f827783d50489c95 --out-dir /Users/namjh/dev/personal/kx-test/target/debug/deps -L dependency=/Users/namjh/dev/personal/kx-test/target/debug/deps --extern byteorder=/Users/namjh/dev/personal/kx-test/target/debug/deps/libbyteorder-72f08eadc904c92b.rmeta --extern digest=/Users/namjh/dev/personal/kx-test/target/debug/deps/libdigest-95aaf4df278b4580.rmeta --extern rand_core=/Users/namjh/dev/personal/kx-test/target/debug/deps/librand_core-d14effafb6afc5e0.rmeta --extern subtle=/Users/namjh/dev/personal/kx-test/target/debug/deps/libsubtle-ed92d0a972977a18.rmeta --extern zeroize=/Users/namjh/dev/personal/kx-test/target/debug/deps/libzeroize-4451ab8183afc3a0.rmeta --cap-lints allow` (exit status: 1)

--cfg 'feature="u32_backend"' --cfg 'feature="u64_backend"' indicates that the both feature is enabled.

[tarcieri]

The problem is the current backend selection for x25519-dalek is feature-based, and features are additive, so if anything else activates either feature they can collide, and the errors as you are experiencing are rather counterintuitive.

The next release of x25519-dalek will migrate to using cfg attributes, which can only be configured by the toplevel binary and are 1-of-n.

When x25519-dalek is upgraded to the next release, this problem will be fixed in perpetuity.

[cr0sh]

Agreed. The weird part is that the kx-test repo only adds crypto_kx as a dependency.