Don't implement Send or Sync on Wasm

[daxpedda]

Checklist

• Run cargo clippy.
• Run RUSTFLAGS=--cfg=web_sys_unstable_apis cargo clippy --target wasm32-unknown-unknown if applicable.
• Add change to CHANGELOG.md. See simple instructions inside file.

Connections
Fixes #2884.
Addresses #3026.

Description
Currently all types unsafely implement Send and Sync on the Wasm target under the assumption that Wasm doesn't support multi-threading. Which it actually does (on nightly).

This PR removes all these implementations and introduces MaybeSend and MaybeSync supertraits to continue implementing Send and Sync on non-Wasm targets.

Testing
It's not, maybe in the future we could add some Wasm multithreading examples/tests.

[daxpedda]

@cwfitzgerald happy to rebase when this is ready to be merged, just hit me up.
Don't want to continuously rebase unnecessarily.

[cwfitzgerald]

I've had a comment queued up for the last 2 months....

The main change this needs is to have a feature to enable Send/Sync on wasm with a scary name like unsound_send_sync_threadless_wasm32 or something

[daxpedda]

The main change this needs is to have a feature to enable Send/Sync on wasm with a scary name like unsound_send_sync_threadless_wasm32 or something

It's quite a big change actually, I removed a lot of those Sendable, I might almost rewrite the PR from scratch.
May I ask why this is necessary?

[daxpedda]

The main change this needs is to have a feature to enable Send/Sync on wasm with a scary name like unsound_send_sync_threadless_wasm32 or something

It's quite a big change actually, I removed a lot of those Sendable, I might almost rewrite the PR from scratch. May I ask why this is necessary?

Just a suggestion, not less work, instead of a crate feature, we could just let Send and Sync be implemented if not(feature = "atomics").

Another one, we could do that this feature only work on not(feature = "atomics") targets, which makes the most sense actually.

Though the disadvantage is that some libraries might rely on this and wouldn't be compatible with atomics then.

[daxpedda]

I added the crate feature. It's all very verbose and I should probably adjust the CI to cover it.
Some documentation of this feature would also be nice.

But before I continue, WDYT @cwfitzgerald?

[cwfitzgerald]

I think this situation is fine, though I'm not sure the feature is technically unsound in this case, as you require atomics to have threads at all.

I'm torn as I think we probably should make it unconditional on atomics, as if someone enables this feature, you get in that same "downstream someone breaks it", but maybe that's a good thing if it would lead to unsoundness.

[daxpedda]

I think this situation is fine, though I'm not sure the feature is technically unsound in this case, as you require atomics to have threads at all.

True, this isn't unsound then. Do you want me to rename the crate feature?

EDIT: I'm gonna deal with CI and docs tmrw.

[cwfitzgerald]

Maybe rename it fragile instead of unsound. Thoughts?

[daxpedda]

Yeah, that sounds fine!

[daxpedda]

I renamed the crate feature to fragile-send-sync-non-atomic-wasm.

[daxpedda]

I couldn't find a central place where all crate features were documented, would like some guidance on where to document this new crate feature.

[daxpedda]

Rebased.

[cwfitzgerald]

Thanks so much for the persistence on this!

[expenses]

Thanks for adding the fragile-send-sync-non-atomic-wasm feature! I just tried this and it broke a ton of stuff as bevy components need to be send + sync: https://docs.rs/bevy_ecs/latest/bevy_ecs/component/trait.Component.html.

[daxpedda]

I guess bevy would need bevyengine/bevy#6689 to support this properly.

FYI fragile-send-sync-non-atomic-wasm doesn't work with target-feature = "+atomics", which requires nightly anyway.