packed_simd dependency does not work with nightly 1.78

[KonradHoeffner]

As of Rust nightly 1.78, the "simd" feature no longer builds due to an error with the packed_simd dependency, which itself depends on the now removed stdsimd feature, see rust-lang/packed_simd#359.

$ rustc --version
rustc 1.78.0-nightly (3246e7951 2024-02-19)
$ git clone git@github.com:sujayakar/rsdict.git
[...
$ cd rsdict 
rsdict$ cargo check -F simd
   Compiling autocfg v1.1.0
   Compiling libm v0.2.8
   Compiling packed_simd v0.3.9
    Checking cfg-if v1.0.0
   Compiling rsdict v0.0.7 (/tmp/rsdict)
   Compiling num-traits v0.2.18
error[E0635]: unknown feature `stdsimd`
   --> /home/konrad/.cargo/registry/src/index.crates.io-6f17d22bba15001f/packed_simd-0.3.9/src/lib.rs:219:5
    |
219 |     stdsimd,
    |     ^^^^^^^

For more information about this error, try `rustc --explain E0635`.
error: could not compile `packed_simd` (lib) due to 1 previous error

[KonradHoeffner]

I tried to address this in #10 but while it builds, it still fails tests, so I need some help there.

[Cydhra]

The functionality of packed_simd can be partially replaced with std::simd by gating the portable_simd nightly feature behind the simd feature of rsdict.
std::simd, unfortunately, does not implement FromBits and IntoBits but offers alternative functionality, so it cannot be used as a drop-in replacement.

Furthermore, it might be viable to look into simdeez as an alternative, because it runs on stable.

[KonradHoeffner]

@Cydhra: Have you looked into #10?
I replaced u8x16::from_bits(u64x2) with core::mem::transmute but I'm not sure if that is correct and whether that is the reason the tests fail.
u64x2::from_bits(__m128i) on the other hand does seem to be equivalent to u64x2::from().

[Cydhra]

So I pull requested into your pull request with a fix for the red tests.

I looked into your transmute code, and I am fairly certain it is correct, since this is also how it was implemented in packed_simd (and also in std::simd as far as I can tell).
If you do not want to call transmute yourself, you could also do u8x16::from(__m128i::from(u64x2::from([lo_mask, hi_mask])));, which I suppose will result in equivalent compiled code, since this also just calls transmute. It looks stupid, but I'm fairly certain it will be optimized away.

[KonradHoeffner]

Resolved in 78c3841.