v1.7 no longer compiles for wasm32

[tomaka]

How to reproduce:

• Clone async-executor
• cargo build --target=wasm32-unknown-unknown

This leads to:

error[E0599]: no method named `get_or_init_blocking` found for struct `async_lock::OnceCell` in the current scope
   --> src/lib.rs:266:20
    |
266 |         self.state.get_or_init_blocking(|| Arc::new(State::new()))
    |                    ^^^^^^^^^^^^^^^^^^^^ help: there is a method with a similar name: `get_or_init`

For more information about this error, try `rustc --explain E0599`.
error: could not compile `async-executor` (lib) due to previous error

Version 1.6 was compiling for wasm32-unknown-unknown just fine.

[Bluefinger]

It seems that for async-lock, the get_or_init_blocking method is just not available for wasm32 platforms, because of the need to not block on the main thread for wasm. Looking at the Executor code, I'm not sure why there's a need for OnceCell within Executor other than to lazily initialise the state. Maybe for WASM, we can't be lazy on the initialisation of the Executor state?

[notgull]

I'm honestly shocked that this compiles on wasm32 in the first place. Nevertheless I've yanked the new version for now.

[Bluefinger]

It's been compiling for a while on wasm32, which is why it is being used in some places for this purpose. Maybe this needs to be added as part of the CI test suite to prevent regressions. Meanwhile, I suggest that async-lock is replaced with once_cell for maintaining the OnceCell but being compatible with wasm32

EDIT: I did the thing #73

[EliottGaboreau]

Hi, it seems even after #75 merged projects using this crate are still having issues, they are failing to compile the crate with this error :

Checking async-executor v1.7.1
error[E0425]: cannot find function `block_on` in module `future`
   --> /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/async-executor-1.7.1/src/lib.rs:281:17
    |
281 |         future::block_on(future::poll_once(
    |                 ^^^^^^^^ not found in `future`
    |

The only way I managed to reproduce this locally by changing changing the Cargo.toml from

[dependencies]
futures-lite = { version = "2.0.0", default-features = false }

[dev-dependencies]
futures-lite = "2.0.0"

to

[dependencies]
futures-lite = { version = "2.0.0", default-features = false }

[dev-dependencies]
futures-lite = { version = "2.0.0", default-features = false }

Looking at the cargo book it seems like the compilation error should have popped up in the CI. I don't exactly know how but it looks like cargo used the [dev-dependencies] vesion of the futures-lite dependency instead of the [dependencies] one when building.

Naive quick fix would be to use default features add features = ["std"] in [dependencies] but I'm not sure how impactful that would be

[taiki-e]

Oh, missed that. I yanked 1.7.1 for now. We should use 2021 edition or v2 resolver or cargo-hack to detect such a issue.

[taiki-e]

Fixed in #77