Skip to content
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

Allow v3, v4, v5 features on wasm32-unknown-unknown #512

Merged
merged 1 commit into from Apr 30, 2021
Merged

Allow v3, v4, v5 features on wasm32-unknown-unknown #512

merged 1 commit into from Apr 30, 2021

Conversation

Expyron
Copy link
Contributor

@Expyron Expyron commented Jan 29, 2021

I'm submitting a feature

Description

The v3, v4, v5 features did not work on wasm32-unknown-unknown in a no_std context.

For v3 and v5, the md5 and sha1 crates are no_std if their default features are disabled, so they work on wasm32-unknown-unknown.

For v4, getrandom can work on any architecture if the root crate registers a custom implementation.

This is not a breaking change, as the other architectures (including stdweb and wasm-bindgen) are not impacted.

Motivation

I wanted to use this crate (especially the v4 feature) on a wasm32-unknown-unknown context that does not have stdweb nor wasm-bindgen.

Tests

The test suite unfortunately does not run on wasm32-unknown-unknown.
The v3, v4, v5 features work properly, as I was able to use them from a dependent crate.

@KodrAus
Copy link
Member

@KodrAus KodrAus commented Jan 30, 2021

Thanks for the PR @Expyron!

I’m a little unsure about committing to getrandom here by guaranteeing a registered implementation will work, but otherwise this seems totally reasonable to me!

@Expyron
Copy link
Contributor Author

@Expyron Expyron commented Jan 30, 2021

I also want to point out that getrandom will refuse to compile on an unsupported target if a custom function is not provided, with a clear error message:

error: target is not supported, for more information see: https://docs.rs/getrandom/#unsupported-targets

That error message would be preferable to the current behavior, which is that Uuid::new_v4() is not defined at all.

API documentation for the Rust `getrandom` crate.

@lastmjs
Copy link

@lastmjs lastmjs commented Apr 2, 2021

Is there anything holding this up? I'm starting to develop on DFINITY's Internet Computer, which is a custom WebAssembly environment, and it doesn't like like I can use UUID easily until this is fixed

@kinggoesgaming
Copy link
Member

@kinggoesgaming kinggoesgaming commented Apr 30, 2021

bors r+

@bors
Copy link
Contributor

@bors bors bot commented Apr 30, 2021

Build succeeded:

@bors bors bot merged commit 2f52aee into uuid-rs:master Apr 30, 2021
21 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants