Fix x86 compilation

[PigeonF]

Compiling for the i686-unknown-linux-gnu target leads to multiple compilation failures.

The first set was easy to solve (akin to #246). The second issue is that std::arch::x86_64::_mm_cvtsi128_si64 does not seem to have an equivalent for std::arch::x86. I think this is an oversight in std::arch::x86?

I am not confident enough in my SIMD knowledge to create a clever workaround, so I copied the "native rust implementation" for x86. If there is some workaround without using _mm_cvtsi128_si64, then feel free to change it.

Note

I do not have a x86 system myself, so I could not test the changes locally. I only checked by running cargo build --target i686-unknown-linux-gnu

[Licenser]

nice catch and good solution. Using the native implementation is fine, 32-bit x86 systems are rare these days so I don't think it'll have a wide impact and with LLVM's optimisations it'll be plenty fast.

I suspect that the reason _mm_cvtsi128_si64 doesn't exist in x86 is that it returns a 64 bit value and the x86 cpu's don't have registers to fit that into nicely.

The arch alias is a nice addition too, I never thought of that but it's much cleaner, I learned some new trick here :) thanks!

There are a few issues with the tests since we got a new clippy lints, those are not related to your changes I think. I'm happy to fix those in the main branch and rebase your PR tomorrow if you don't want to deal with them.

CI aside, PR looks great 👍 thanks!

[PigeonF]

There is one more clippy lint that is reported on nightly: missing_transmute_annotations, specifically for

simd-json/src/macros.rs

Lines 1253 to 1259 in 83a806f

	/// static cast to an i8
	#[macro_export]
	macro_rules! static_cast_i8 {
	($v:expr) => {
	::std::transmute::<_, i8>($v)
	};
	}

I am not sure if you want to just ignore the lint here or not, so I have not done anything about them. Properly fixing the lint would probably involve removing the macros and calling transmute directly instead, which seems like a whole lot of effort. On the other hand, I am not familiar with the code base, so I am not comfortable deciding that the lint should be ignored 😅

[PigeonF]

I am not too sure about the portable config (i.e. is the config supposed to be "hidden", or is this just remainder from previous code), so I have elected to ignore the warning about it here.

[PigeonF]

I believe the previous implementation was buggy: the clippy lint indicates that it would have looped infinitely.

I think comparing the wrapped value is what was intended here?

[Licenser]

Yes that's right! Good catch :)

I stumbled about that the other day too, clippy is my secret hero to be honest 😂 it avoids so many issues.

[Licenser]

Perfect :) thank you so much!

[Licenser]

Sorry it took me so long to merge this, I thought I had done it and must have forgotten.