rand 0.5.1 no longer compile for wasm32-unknown-unknown

[sebcrozet]

It appears the release 0.5.1 breaks compilation for the wasm32-unknown-unknown target.
I understand that activating the stdweb feature fixes the compilation error, but it seems wrong to just fail to compile if stdweb is not selected. Instead, the part of rand that require stdweb should be deactivated by conditional compilation when we target wasm32-unknown-unknown without activating the stdweb feature.

[sebcrozet]

After comparing with the version 0.5.0, it seems this has been rewoved:

#[cfg(all(target_arch = "wasm32",
          not(target_os = "emscripten"),
          not(feature = "stdweb")))]
mod imp {
    use {Error, ErrorKind};

    #[derive(Clone, Debug)]
    pub struct OsRng;

    impl OsRng {
        pub fn new() -> Result<OsRng, Error> {
            Err(Error::new(ErrorKind::Unavailable,
                           "not supported on WASM without stdweb"))
        }

        pub fn try_fill_bytes(&mut self, _v: &mut [u8]) -> Result<(), Error> {
            Err(Error::new(ErrorKind::Unavailable,
                           "not supported on WASM without stdweb"))
        }
    }
}

Removing this was a breaking change for rand since this broke compilation of downstream crate that don't activate the stdweb feature.

[pitdicker]

There seems to come no end to the trouble wams-unknown-unknown causes us 🙁. Thank you for reporting!

We have two options:

• add back the "not supported" stub (and in this case for all unsupported platforms)
• configure out OsRng on unsupported platforms.

I think the second option is the best choice, as it moves the error from runtime to compile-time. (The error will only occur when someone uses OsRng on an unsupported platform, not always as is the bug this issue is about.) The solution for crates is to work everywhere is to use EntropyRng instead of OsRng.

But technically that is a breaking change. Maybe we should just to the sub-optimal fix in the 0.5 branch, and make OsRng unavailable in 0.6.

[dhardy]

So @sebcrozet you were using WASM without stdweb or emscripten? I was sceptical from the start about failing with a run-time error when the required features were unavailable, but was told this was the way std were doing it.

We could configure out OsRng as mentioned, but this will also remove thread_rng, EntropyRng and FromEntropy.

[dhardy]

For quicksilver they apparently didn't realise the stdweb feature can be used.

but it seems wrong to just fail to compile if stdweb is not selected. Instead, the part of rand that require stdweb should be deactivated by conditional compilation when we target wasm32-unknown-unknown without activating the stdweb feature

I agree, this should be the preferred solution. Assuming no objections, I think we should just implement this for 0.5.2 (even though it's technically a breaking change from 0.5.0).

[dhardy]

Fixed by #512 (and #514). Will be released in 0.5.2 soon.

Is someone (@sebcrozet?) able to test using the 0.5 branch? I.e.:

rand = { git = "https://github.com/rust-lang-nursery/rand", branch = "0.5" }

[sebcrozet]

Great, thanks @dhardy ! I confirm the 0.5 branch compiles for wasm32-unknown-unknown without the stdweb feature.

Edit: thanks to @pitdicker as well for making the PR!