Update async-executor to 1.3.0 (urgent)

[ghost]

For anyone who stumbles on this issue wondering what went wrong:

The easiest fix until this PR is merged is to add this as a dependency to your Cargo.toml:

[dependencies]
async-executor = "=1.2.0"

---

Hey, I sneaked in a small breaking change into async-executor without respecting semantic versioning rules.

The change is to parametrize executors over a lifetime, i.e. turn Executor into Executor<'a>. This way, we can have non-static executors, spawn non-static futures, and await their non-static results! :)

Rather than bumping async-executor to v2.0, I chose to sneak in the breaking change into v1.3.0 for the following reasons:

• async-executor v1.x is still very new and few projects are using it.
• Most projects using it are not affected by the breaking change (yours is one of the two unfortunate ones I found).
• Bumping to v2.0 would require smol to go v2.0 too, thus creating a lot of churn.

The short story is: respecting semver rules would overall cause us more pain that just merging this one pull request. The other affected project, async-global-executor, is already fixed).

Anyways, apologies for that! I hope you can just quickly merge this in and move on :)

Cheers! This looks like a cool project, I'm actually gonna go look what's inside...

TL;DR for anyone whose code is broken right now: add async-executor = "=1.2.0" to Cargo.toml as a temporary workaround.

[ghost]

Oh, I forgot to add - async-executor v1.3.0 will allow you to get rid of most of other unsafe code in bevy_tasks, especially those transmutes. I can try to do that after this PR gets merged!

And, by the way, I have noticed your API is at least somewhat inspired by crossbeam::scope(). Have you perhaps seen easy-parallel crate? It allows you to do almost the exact same thing, except with a much simpler API and simpler implementation.

Here you can see a nice example combining async-executor and easy-parallel: https://docs.rs/async-executor/1.3.0/async_executor/struct.Executor.html#examples

[CleanCut]

I hit this error this morning and came looking for why Bevy 0.2.0 was suddenly broken. (Thanks @stjepang for following up with the fix!)

I confirmed that this now builds and a bunch of examples I spot-checked (breakout, etc.) all worked correctly.

I suggest merging this and putting out 0.2.1 to unbreak the world.

[loriopatrick]

Just created, #532 will close :).

[navaati]

Has anyone got an idea of why the Cargo.lock was not enough to protect the bevy crate itself from this breakage ? (I understand that it doesn’t protect users of the crate, that have their own Cargo.lock)

[cart]

Looks good. Thanks for the quick responses!

[CleanCut]

@navaati Libraries like Bevy do not include Cargo.lock as a general rule, so it can't protect from this sort of problem. This is why the Rust ecosystem takes semantic versioning very seriously -- things break otherwise. If libraries included their own Cargo.lock files, then various dependencies of different libraries would fight to lock on different specific versions of shared dependencies, exploding binary size and compilation time.

For more info on that subject check out the Cargo.toml vs Cargo.lock chapter of The Cargo Book.