-
Notifications
You must be signed in to change notification settings - Fork 236
unsupported opt-in backend
#667
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
c0538d9 to
903c641
Compare
903c641 to
b7384b7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks mostly good, but I am not sure about the backend name. How about unsupported since it returns Error::UNSUPPORTED?
I wasn't sure about it either. Yeah, I like that better. Updated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will leave this PR open for some time for @josephlr to take a look on it. Plus we need to fix the failing CI jobs (it looks like a Nightly toolchain issue).
|
Also, please add a changelog entry. You can add the following section: The diff link goes to the end of the file. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks reasonable to me. Thanks for adding this!
I'm going to try to see if the CI errors are just spurious failures or something we need to fix. Regardless, the failures aren't being caused by this PR.
|
Thank you! We probably will wait for some time before releasing v0.3.4 to accumulate other potential changes. Meanwhile, you could temporarily patch |
## [0.3.4] - 2025-10-14 ### Major change to `wasm_js` backend Now, when the `wasm_js` feature is enabled, the `wasm_js` backend will be used by default. Users of `wasm32-unknown-unknown` targeting JavaScript environments like the Web and Node.js will no longer need to specify: ``` --cfg getrandom_backend="wasm_js" ``` in `RUSTFLAGS` for the crate to compile. They can now simple enable a feature. Note: this should not affect non-JS users of the `wasm32-unknown-unknown` target. Using `--cfg getrandom_backend` will still override the source of randomness _even if_ the `wasm_js` feature is enabled. This includes `--cfg getrandom_backend=custom` and `--cfg getrandom_backend=unsupported`. For more information, see the discussions in [#671], [#675], and [#730]. ### Added - `unsupported` opt-in backend [#667] - `windows_legacy` opt-in backend [#724] ### Changed - Implement Memory Sanitizer unpoisoning more precisely [#678] - Relax MSRV for the `linux_raw` opt-in backend on ARM targets [#688] - Use `getrandom` syscall on all RISC-V Linux targets [#699] - Replaced `wasi` dependency with `wasip2` [#721] - Enable `wasm_js` backend by default if the `wasm_js` feature is enabled [#730] ### Removed - Unstable `rustc-dep-of-std` crate feature [#694] [#667]: #667 [#671]: #671 [#675]: #675 [#678]: #678 [#688]: #688 [#694]: #694 [#699]: #699 [#721]: #721 [#724]: #724 [#730]: #730 --------- Signed-off-by: Joe Richey <[email protected]>
An alternative to #666 that errors at runtime.
This is useful when needing the crate to compile when targeting wasm32, but this code is never actually hit.