Right now, while our implementations for stdweb and wasm-bindgen use
similar APIs, they do not use similar implementations. This change:

  - Switches to using the same error codes for both implementations
  - Uses error codes that detail exactly what API is missing
  - Cleans up the implemetnations to make them much more readable
  - Consitantly use thread_local in both implementations

This makes issues easier to debug and the code easier to understand.

Signed-off-by: Joe Richey <joerichey@google.com>

Signed-off-by: Joe Richey <joerichey@google.com>

Signed-off-by: Joe Richey <joerichey@google.com>

Apply #137 to 0.2 branch

travis: Allow nightly builds to fail

The type of the `rnd` parameter is SecRandomRef which is an alias for an
"Opaque Pointer". This is better represented in Rust as a c_void pointer.

We also know that kSecRandomDefault is NULL, so we can simplify the code.

https://developer.apple.com/documentation/security/1399291-secrandomcopybytes
https://developer.apple.com/documentation/security/secrandomref
https://developer.apple.com/documentation/swift/imported_c_and_objective-c_apis/using_imported_c_functions_in_swift

As our minimum rust version is 1.33, we can just use `target_vendor`.

- Use debug asserts in code
- Use normal asserts in tests
- Use *assert_eq! methods when possible
- Remove unnecessary asserts

Also make Error::code a const fn. These increase the Min Rust version to 1.33

travis: Fix wasm32 CI

Split emscripten stuff into its own target and stop relying on cargo web
to download/manage then emscripten toolchain. We can just get it
ourselves. We also now run the emscripten tests.

Signed-off-by: Joe Richey <joerichey@google.com>

Also add tests for 32-bit x86

This allows us to verify the RDRAND implementation on Linux.

Signed-off-by: Joe Richey <joerichey@google.com>

- Cleanup .travis.yml
  - Loops over std/no_std targets
  - Remove deprecated/useless keys
  - No more `cd`, we just use `--package`.
- Improve tests
  - Main `getrandom` tests are now unit test modules instead of
    integration tests, making the code cleaner.
  - The custom RNG crates now use this common module as part of their
    integration tests.
  - No more weird test-only features needed to get the crate to build.

Signed-off-by: Joe Richey <joerichey@google.com>

This allows freestanding targets to use getrandom.

Signed-off-by: Joe Richey <joerichey@google.com>

We will use a more generic "cpu" mechanism to support these.

Signed-off-by: Joe Richey <joerichey@google.com>

Signed-off-by: Joe Richey <joerichey@google.com>

This feature isn't enabled by rand/rand_core and provides very little
error information that isn't already conveyed through our Error values.

This also simplifies the supported configuration space for getrandom.
We update the docs and CI to match this change.

Signed-off-by: Joe Richey <joerichey@google.com>

We no longer use spin-locks anywhere in getrandom, so remove any
interfaces which spin.

Signed-off-by: Joe Richey <joerichey@google.com>

Don't spin when polling /dev/random. We also remove the use of spin
locks when opening the persistent fd for platforms that require it.

For both these cases, we can just use the pthread lock/unlock methods
in libc. This includes adding Mutex and DropGuard abstractions.

Signed-off-by: Joe Richey <joerichey@google.com>

Signed-off-by: Joe Richey <joerichey@google.com>

Right now for each of `util_libc` and `use_file` we have a list of
`target_os` configs to determine if we build the module.

This PR moves these mod declarations into the main `cfg_if` statement
(the one that selects which implementation we use). This way, the mod
statements are kept in-sync with the implementations that use them.

Also, I merged together `target_os` cfgs that have the same
implementation. The downside to this is that the targets are no longer
in alphabetical order.

Also, this is only being applied to `0.2` as the `0.1` cfgs still have
to keep `std` around.

Rename it from freebsd.rs to sysctl_arandom.rs.

NetBSD has been patching rustc for some time to use the FreeBSD
implementation because every single invocation of the compiler
may drain from the entropy pool and cause the next to block.

This can massively inflate build times for rust software, or cause
it to fail entirely, especially in VMs (for example, our Xen package
building cluster).