Cannot use async-await feature with no_std

[Nemo157]

Attempting to compile a crate depending on futures with the async-await feature active (for join! and select!) fails when the target doesn't have std.

With the following dependency:

[dependencies.futures-preview]
version = "0.3.0-alpha.18"
default-features = false
features = ["async-await", "nightly"]

compiling fails for thumbv7m-none-eabi with:

> cargo build --target thumbv7m-none-eabi
[...]
error[E0463]: can't find crate for `std`
error: Could not compile `futures-core-preview`.
[...]
error[E0463]: can't find crate for `std`
error: Could not compile `lazy_static`.

std is currently necessary because of the randomness inherent in select!, so fixing this will likely overlap with #1805, maybe by providing some way to provide the source of randomness to select!.

[arcnmx]

Should this be reopened? I'm not quite sure how #1837 addressed this:

1. Make async-await feature not depend on std feature #1815 introduced a cfg(std) on futures_util::async_await and thus the module isn't being compiled or used on no_std platforms. The example above compiles now but only because the async-await feature doesn't actually do anything.
2. Remove rand dependency by using our own PRNG #1837 helped push this along but doesn't make any of the modules/macros available and the prng isn't no_std compatible (it uses std::thread_local! and also has std:: imports).

Not that making the prng no_std compatible will magically make everything else work but I imagine the intention here was to track that the pieces required for it are in place?

[taiki-e]

@arcnmx

#1837 only fixed the compile failure.
However, async-await with no-std is not officially supported.
And, If I understand correctly, async-await implementations based on generators and proc-macro are not compatible with the macros provided by futures due to macro expansion order.

That said, #1837 made no-std support very easy.
Perhaps just remove hashing and cfg(feature = "std").

#1837 didn't do this because it wasn't clear how much we should support a way that isn't officially supported.
I planned to do this when it is officially supported, but if someone is actually using those hacks and wants to add support to futures, I think we can do it now.

Related:

• Make async-await feature not depend on std feature #1815

  async-await feature depends on std feature because feature(async_await) is currently not available with no-std, but it would be preferable to separate these features because they might be usable with no-std in the future.

• Cannot define async fn with no_std rust#56974

• Remove TLS dependency from async/await rust#62918

  This makes usage in no_std environments quite difficult.

[arcnmx]

#1837 only fixed the compile failure.

Ah, I think what confused me was that it mentioned this issue while it didn't seem to change anything related to that, but I think the answer is that #1815 wasn't quite enough to fix this because of how the futures supercrate enables the macro feature. That makes it more clear as to why this issue was mentioned, sorry about that.

However, async-await with no-std is not officially supported. And, If I understand correctly, async-await implementations based on generators and proc-macro are not compatible with the macros provided by futures due to macro expansion order.

That's true, but not the only way to approach the problem.

That said, #1837 made no-std support very easy.

Yeah, my intention more than anything was to point out how close it is to supporting no-std, which would put the rest of the burden/blocker purely on upstream rust. It seems reasonable to aim to still generate valid code, or at least export the macros that truly don't require anything from std.

if someone is actually using those hacks and wants to add support to futures, I think we can do it now.

Oh you mentioned it directly, yeah that.