Cranelift: workaround for crash when loading .png files on arm64

[wyvernbw]

This gave me quite a headache and i don't know if its a bevy issue specifically but if you're using cranelift on arm64 and trying to load a png file you might get a

thread 'IO Task Pool (1)' (8474476) panicked at library/core/src/panicking.rs:225:5:
llvm.aarch64.crc32b is not yet supported.
See https://github.com/rust-lang/rustc_codegen_cranelift/issues/171
Please open an issue at https://github.com/rust-lang/rustc_codegen_cranelift/issues
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread caused non-unwinding panic. aborting.

the quick fix is to pin crc32fast to something smaller than 1.5 and make sure to not use the nightly feature.

crc32fast = ">=1.2, <1.5"

i tested 1.2, 1.3, 1.4 and they work.
the png crate depends on crc32fast which is where this issue comes from, see rust-lang/rustc_codegen_cranelift#171

should i open an issue in bevy?

[mockersf]

crc32fast is not a direct dependency of Bevy, so we probably shouldn't do anything about it.

The last comments on the rustc_codegen_cranelift issue you mentioned says that bjorn3 could work on it, but a minimal reproducer would probably help them to test they are doing it right

Bevy paths to this crate:

bevy_image v0.17.0-dev (crates/bevy_image)
├── image v0.25.6
│   └── png v0.17.16
│       ├── crc32fast v1.5.0
│       ├── flate2 v1.1.2
│       │   ├── crc32fast v1.5.0 (*)

You could check with crc32fast, png or flate2 if they want to work on this, but I think the issue in rustc_codegen_cranelift is enough.

[wyvernbw]

yeah, thats what i thought as well, just wanted to leave this here in case anyone runs into the same problem, especially with the new hotpatching feature since it pretty much goes hand in hand with the faster codegen backend