This allows users to get an actionable error message about this
particular problem. We also add detection for this problem.
Signed-off-by: Joe Richey <joerichey@google.com>
* add description about Cargo js feature
* add note about different crate types
* clean up
* Fix wording/grammer
* Remove "Indirect Depenencies" section
* Note that libraries shouldn't add their own JS feature
Signed-off-by: Joe Richey <joerichey@google.com>
Co-authored-by: Mauri Mustonen <mauri.mustonen@hotmail.com>
Co-authored-by: Joe Richey <joerichey@google.com>
They will be gated behind the "js" feature, as we can now do detect,
at compile-time, which implementation (wasm-bindgen vs stdweb) we
should use.
The "js" implementation takes precedence over the "custom"
implementation. This prevents issues that arise from the buggy way
Cargo handles features across multiple targets.
Signed-off-by: Joe Richey <joerichey@google.com>
Right now, features are always enabled across all targets. This means
that if _any_ Custom RNG is used _anywhere_ in a crate's dependancy
graph on _any_ target. The "custom" feature will be active on all
targets.
This makes it impossible to have a bare metal target that uses "cpu" on
x86_64 and a Custom RNG on aarch64. This solution also makes sure that
any implementation `getrandom` itself provides cannot be overridden.
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 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.
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.
Joe Richey
Mauri Mustonen
Artyom Pavlov
Autumn
Mark Drobnak
Þórhallur Sverrisson
Stewart Mackenzie
Tomoaki Kawada
Tobias Klauser
Tobias Klauser
Robin Appelman