Fix a compile error for certain feature combo.

[vdods]

cargo build --features secp256k1,secp256r1,sha2 was failing with
a compile error in ssi::hash::sha256. This fixes that.

[vdods]

Hold off on this one too. Related to #451

[vdods]

Ok, I've got an explanation for the confusing behavior I was encountering. I think the target-based dependencies work as one would expect. However, within the sha256 function in hash.rs, the choice of implementation is gated on the "sha2" feature, which is an implicit feature because it's an optional crate. Where things go wrong is that the bs58 crate (a dependency of ssi crate) imports the sha2 crate, which causes the "sha2" feature to be enabled, and so the "ring" and "sha2" features actually can't be mutually exclusive.

I ran into this trouble while trying to get a wasm build running, where currently ring doesn't fully support wasm (it builds but wasm-pack produces a build which is not usable due to briansmith/ring#918). Using cargo tree to track down mutually incompatible features has been troublesome because there are several places where a crate's default feature includes a feature which is mutually incompatible with another feature.

Anyway, I'm going to take another stab at this. The goal (at least within my codebase) is to make wasm builds use target-specific dependencies and not use a "wasm" feature, which unfortunately seems to have been the choice of many other crates. This has been a problem because often wasm-specific features are mutually incompatible with non-wasm -- clear_on_drop for example, to be used in a wasm build, requires features = ["no_cc"], as in #451

[vdods]

This is good to go now. This uses the "ring" crate if available to implement ssi::hash::sha256, otherwise will use "sha2" crate, otherwise will panic with unimplemented. Let me know if this isn't the right behavior, and I can can change it to something else suitable.

[sbihel]

Hey, I'm not a fan of these changes. I would prefer to have the compilation fail if a necessary feature is disabled. But I agree that if both ring and sha2 are enabled, it should simply pick one implementation.

[vdods]

That's totally fair!

I'd like to figure out what specific change to make. To describe the challenge here, the use of the function crate::hash::sha256 occurs in 3 different ways -- one is not gated behind any feature, one is gated behind feature "k256", and one is gated behind feature "rsa". So there needs to be an implementation of sha256. Because the implementation of sha256 requires either "ring" or "sha2", there seems to be a bit of a gap. In the existing implementation, the definition of the sha256 function itself was gated on features "ring" or "sha2", and the compile would fail without a clear explanation if neither of those features were activated. I personally agree with having the compilation fail if a necessary feature is disabled.

What I can do is change the "unimplemented!" line in sha256, in which neither "ring" nor "sha2" are enabled, to "compile_error!", which would cause a compile error if the features necessary to provide an implementation for sha256 are not provided. I believe this should meet your request. Does that sound good to you?

[sbihel]

compile_error! is a good idea!