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

Support building on webassembly #137

Open
detrumi opened this issue Mar 23, 2019 · 6 comments · May be fixed by #270
Open

Support building on webassembly #137

detrumi opened this issue Mar 23, 2019 · 6 comments · May be fixed by #270
Labels
feature-request This issue is requesting new functionality

Comments

@detrumi
Copy link

detrumi commented Mar 23, 2019

It would be great if proptest could be built on WASM. Slightly related to #47 but more specific, since proptest can almost be compiled to webassembly already.

I'm already disabling the default forking feature, to avoid the rusty-fork dependency.

The only thing blocking building proptest on webassembly is these few lines, importing std::os::unix inside a #[cfg(not(target_os = "windows"))] block.

Could the osstring_invalid_string function be constrained more, by excluding wasm32 for example? Or maybe there's a better solution to avoid using std::os::unix on all non-windows targets?

@matklad
Copy link

matklad commented Mar 23, 2019

A possible solution here would be to split proptest into two crates:

  • a proptest-traits, which exposes strategy trait and related machinery. This part could be strictly pure & platform-independent I think?
  • proptest-runner, which allows one to actually run property test, maintaining a failure database, etc.

EDIT: this would help because we depend on prop-test in a non-optional way to define an "Arbitrary" instance for text edits. It would be totally fine if the actual tests work on Linux/Windows/Mac.

@AltSysrq
Copy link
Collaborator

I gated the code you deleted behind a cfg check in 0.9.2, so I think it should be working for you now.

split proptest into two crates

Unfortunately, the two are rather intertwined — even the basic public API requires Strategy to know about TestRunner and vice versa.

@AltSysrq AltSysrq added the feature-request This issue is requesting new functionality label Mar 24, 2019
@lastmjs
Copy link

lastmjs commented Aug 7, 2021

Were any of you able to get proptest to compile for WebAssembly? I am running into this error:

error[E0433]: failed to resolve: use of undeclared crate or module `imp`
  --> /home/lastmjs/.cargo/registry/src/github.com-1ecc6299db9ec823/wait-timeout-0.2.0/src/lib.rs:66:9
   |
66 |         imp::wait_timeout(self, dur)
   |         ^^^ use of undeclared crate or module `imp

@lastmjs
Copy link

lastmjs commented Aug 7, 2021

I turned off all features except for std, and it now compiles.

Have you had success actually getting proptest to run? I keep getting a panic when trying to create a runner: Panicked at 'not supported on this platform', library/std/src/sys/wasm/../unsupported/os.rs:76:5

@RReverser
Copy link

^ that's about how far I got too, with a more precise message in a few places:

panicked at 'condvar wait not supported', library/std/src/sys/wasm/../unsupported/locks/condvar.rs:23:9

RReverser added a commit to RReverser/proptest that referenced this issue Aug 31, 2022
Hides a few paths, that fail at runtime on wasm32-unknown-unknown, under conditional compilation.

Fixes proptest-rs#137.
@RReverser RReverser linked a pull request Aug 31, 2022 that will close this issue
RReverser added a commit to RReverser/proptest that referenced this issue Aug 31, 2022
Hides a few paths, that fail at runtime on wasm32-unknown-unknown, under conditional compilation.

Fixes proptest-rs#137.
@mlodato517
Copy link

mlodato517 commented Aug 18, 2023

🤦 Just saw #270

Ignore

I tried a minimal reproduction with wasm-pack and wasm_bindgen_test like:

proptest! {
    #[wasm_bindgen_test]
    fn some_test(num: u32) { assert_eq!(num, num); }
}

And ran into three failures:

  • Two were usages of Instant::now in runner.rs. Not sure if those can/should be grouped under the timeout feature. If so, that'd be convenient and I'd happy to PR that.
  • The other one was env vars in the config and I have no idea what to do about that 😅

Neither of these address the more niche cases like condvar mentioned above but maybe we can iteratively approach WASM support by handling something like that minimal reproduction first? Happy to help if anyone has bandwidth to offer any guidance!

bmwill pushed a commit to bmwill/proptest that referenced this issue Feb 23, 2024
Hides a few paths, that fail at runtime on wasm32-unknown-unknown, under conditional compilation.

Fixes proptest-rs#137.
bmwill pushed a commit to bmwill/proptest that referenced this issue Jun 4, 2024
Hides a few paths, that fail at runtime on wasm32-unknown-unknown, under conditional compilation.

Fixes proptest-rs#137.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request This issue is requesting new functionality
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants