Remove cloudabi, winapi, and fuchsia-cprng dependancies

[josephlr]

Depends on #39 and helps address issues raised in rust-lang/rust#62082 (comment)

We don't really need these external crates as they just provide declarations of system functions that we can just extern declare ourselves.

This PR also updates the docs and cleans up Cargo.toml to explain why we need lazy_static on certain targets.

This also fixes the fuchsia CI issues.

[newpavlov]

I also prefer to keep those extern's inside getrandom instead of depending on platform crates, but @dhardy had a different opinion at the time.

[dhardy]

I'm not too fussed; seems sensible enough to avoid the dependencies in this case.

[newpavlov]

Can you fix the CI failure and rebase (otherwise right now PR contains formatting changes)?

[josephlr]

Can you fix the CI failure and rebase (otherwise right now PR contains formatting changes)?

Done

[newpavlov]

I don't think we want to depend on libc for all targets. Maybe instead construct one big cfg expression with enumeration of targets which use libc?

[josephlr]

Done, I just used unix || wasi. Although that's not perfect, as we don't use libc on all unix targets (only 7 of them), but writing all that out makes the Cargo.toml way harder to read.

[newpavlov]

We also could remove libc dependency for WASI as well, libc code is quite straightforward. Not sure if it's worth though.

[josephlr]

We totally could (Strictly speaking we could do it for any libc declaration), but I think it’s best to not duplicate declarations from the libc, if possible.

[josephlr]

If we wanted we could not depend on the libc at all for any target, by copying over the 6 or 7 libc declarations needed to make everything link. But I think that would make breakage/instability more likely, not less.

[newpavlov]

It's just a bit strange for me to depend on libc crate for a target which, well, does not have libc as a system interface, i.e. it's defined in terms of core functions. (I wonder why WASI target was added to libc crate in the first place, instead of creating a separate crate à la cloudabi or Fuchsia crates)

[josephlr]

So I think they added it because wasi-libc defines that symbol. However, it's just a macro that links to the wasi_unstable module. From their Github issues, it seems like the wasi_unstable module is an implementation detail and may change in the future.

Given that, linking to the libc seems like the most stable approach, so we are not depending on an unstable components of the WASI API.

[newpavlov]

In my understanding we shouldn't care about wasi-libc at all. WASI defines Core API and __wasi_random_get is part of it. So we should be able to use it directly without any issues.

cc @alexcrichton @gnzlbg

UPD: Ah, the linked page states that:

The function names are prefixed with "_wasi" to reflect how they are spelled in flat-namespace contexts, however at the wasm module level, they are unprefixed, because they're inside a module namespace (currently "wasi_unstable").

So it looks like random_get (to which __wasi_random_get links) is unstable. I don't quite get this situation, but it seems that using libc will be indeed the best option right now.

[dhardy]

Can I leave this to you @newpavlov and @josephlr?

[newpavlov]

Yes, I will do the merge after we will decide if we want to depend on libc for WASI target.