nfa::contiguous::tests::swar test failure on s390x (and possibly all big-endian architectures)

[decathorpe]

I'm maintaining the Fedora Linux package for this crate, and upon the update from v0.7 to v1.0, I see new test failure on s390x / IBM System Z (i.e. s390x-unknown-linux-gnu):

failures:
---- nfa::contiguous::tests::swar stdout ----
thread 'nfa::contiguous::tests::swar' panicked at 'assertion failed: `(left == right)`
  left: `0`,
 right: `3`', src/nfa/contiguous.rs:1116:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
failures:
    nfa::contiguous::tests::swar

Looking at the code for this test, it's not surprising that it might fail on systems with big-endian byte order, given that most constants are hard-coded hex literals, and the function relies heavily on bitmasks / bitshifts / etc.

Reading the comment above the test, it sounds like this functionality isn't actually used in the aho-corasick crate but only kept "for posterity"? I will ignore the failure for now, but it might make sense to document that this code doesn't work as expected on big-endian architectures, or gate it behind something like #[cfg(target_endian = "little")]?

[BurntSushi]

Thanks! Yeah, this doesn't impact the "real" code.

Like #116, this also should have been caught by CI. Namely, CI includes mips64-unknown-linux-gnuabi64, which tests on big-endian. Running tests locally results in a failure. So I'm not sure why this wasn't caught.

[BurntSushi]

It was me being dumb. I wasn't passing $TARGET to the Cargo build commands, so while cross was running, it was just using the host target.

[decathorpe]

Great, thanks for confirming!

And well, at any rate, the CI should be more robust now 😅