Potentially using wasmv1-none

[workingjubilee]

Issue opened to discuss the possibility of using the wasmv1-none target in 1.84, as raised by rust-lang/rust#131487 (comment)

[danielhjacobs]

To copy some things over from Discord:

The benefits:

• Support for Safari 14.1 continues (not really necessary, very much EOL)
• Support for Pale Moon continues: https://forum.palemoon.org/viewtopic.php?f=70&t=31740#p256587, Moonchild says "these extensions in Firefox were tied to a specific Rust codegen methodology (cranelift) i.e. using Rust to generate wasm machine code; and now as a result requiring clients to interpret this extended (not baseline) wasm code, and guess what Mozilla used for this? That's right, their Rust implementations in Firefox. Since we don't support Rust in our development I don't think we will ever be able to follow that particular trail of breadcrumbs as it fully relies on processing wasm with Rust on the client side. I may still be misunderstanding how all of these pieces fit together but it does look like these are extensions to wasm that aren't possible to implement as they are. On top the cranelift codegen has, apparently, not been continued in Firefox/mozilla-central (if I go by the scattered BZ bugs) and the state of the code interpreter at Mozilla's client side is unknown as a result. If this is simply a matter of pushing optional extensions because Rust wants everything to be Rust (typical) then I'd appreciate it if someone helps us either to make a shim..."
• Other non-mainstream browsers may be able to more easily support Ruffle as they won't need to support the ever-evolving feature-set of the wasm32-unknown-unknown target.
• @n0samu reports Safari 15 seems to have some bugs with reference-types. It theoretically is meant to support them but it seems in practice there are issues. Without this, we may need to drop support for Safari 15 as well, which is slightly more unfortunate as it's still supported by security updates.

Concerns from @adrian17, for which the answers seem to all be no:

the questions relevant for us are

• is std:: accessible (even if it only re-exports stuff from core::)
• is std::sync:Mutex available
• are functional parts (that don't touch the OS themselves) like std::path::Path or std::time::Duration available

The major issue:

• We would need changes to https://github.com/search?q=repo%3Aruffle-rs%2Fruffle+std%3A%3A+path%3Aweb%2F&type=code and https://github.com/search?q=repo%3Aruffle-rs%2Fruffle+std%3A%3A+path%3Acore%2F&type=code: That's a lot of files and may not be worth it.

Some statements from @moulins:

For std::time::Duration, we could probably replace them with the time crate, I see that they have a wasm-bindgen feature
For std::path::Path, tbf it seems like a bug if it's used in ruffle_core, given that it's OS-specific
The lack of std::sync is annoying though, I don't know what to do about it
why do we need Arc/etc in core again? for audio/gpu stuff, because they happen in a separate thread on desktop?

Reply from @adrian17:

maybe also for async stuff?

[danielhjacobs]

According to moulins:

the lack of sync types is the big blocker imho
the Read/Cursor stuff too, even if it could be replaced with (a lot of) work

[danielhjacobs]

Note that on Discord, it was determined that:

1. We may just listen to what the docs say to do in https://github.com/rust-lang/rust/blob/master/src/doc/rustc/src/platform-support/wasm32-unknown-unknown.md#enabled-webassembly-features:

   Otherwise -- if you need std, or if you need to target the ultra-minimal "MVP" feature set, excluding mutable-globals -- you will need to manually specify -Ctarget-cpu=mvp and also rebuild the stdlib using that target to ensure no features are used in the stdlib. This in turn requires use of a nightly compiler.

   and commit ourselves to use nightly for releases, unfortunately. Note that dev and desktop builds can still use stable, in practice only the CI and release needs no-extension builds

2. We should definitely minimize our use of std features in core/, web/, and swf/ anyway. However, it may not be able to be fully removed because of the lack of sync types and Read/Cursor.

A future option is to develop a policy of only supporting browsers with the same WebAssembly extension feature set as LLVM. The LLVM project enabled reference-types by default in llvm/llvm-project#93261. Then, in https://github.com/emscripten-core/emscripten/blob/aa3a8a46e2e6365f869b9129f3ce33ac53515679/ChangeLog.md#3162---070224, emscripten followed suit, and according to https://github.com/rust-lang/rust/blob/master/src/doc/rustc/src/platform-support/wasm32-unknown-unknown.md#enabled-webassembly-features, the wasm32-unknown-unknown target inherits the default settings of LLVM which typically matches the default settings of Emscripten as well.

At this time, this would remove our support for Safari 14 definitively. It shouldn't remove our support of Safari 15 theoretically, but in practice Safari 15's reference types implementation seems incomplete (see #18386). However, it's possible LLVM enables other WebAssembly extensions in the future that push our minimum supported browser versions higher.

Currently, Pale Moon doesn't support the reference type extensions either. That may change if https://repo.palemoon.org/MoonchildProductions/UXP/issues/2647 is ever resolved. That will take some work since according to MoonChild "If we want this, we probably need to closely inspect the relevant BZ implementations and specifically only adopt the reftypes parts and not any of the GC structs or templates." It's possible that falls down the priority list.