test failure in regex-automata v0.4.8 on 32-bit x86 (i686) *only* with Rust > 1.79

[decathorpe]

I'm working on updating the regex / regex-automata / regex-syntax crates on Fedora Linux to the latest version, and I'm seeing a strange test failure. It occurs only on i686-unknown-linux-gnu, and appears to only happen with Rust 1.81 (Fedora), but not with 1.79 (CentOS Stream) or 1.75 (RHEL 9). It's one of the doctests that fails:

failures:
---- src/nfa/thompson/compiler.rs - nfa::thompson::compiler::Config::nfa_size_limit (line 229) stdout ----
Test executable failed (exit status: 101).
stderr:
thread 'main' panicked at src/nfa/thompson/compiler.rs:12:6:
called `Result::unwrap_err()` on an `Ok` value: thompson::NFA(

(debug print of big internal state omitted)

)

The test is here: https://github.com/rust-lang/regex/blob/master/regex-automata/src/nfa/thompson/compiler.rs#L229-L247 (I can't link to the automata-0.4.8 tag because recent releases weren't tagged in git, from what I can tell).

Is the size of the NFA smaller on 32-bit architectures? That might explain why the test expects an error but gets an Ok() even with the smaller size limit.

But then I'm not sure why this only fails with Rust 1.81 but not with 1.79 or 1.75. Maybe a new niche / layout optimization?

It doesn't look like this is a bug in the implementation per se, so I will skip this test for now. But I still wanted to report it in case there's something more going on.

[BurntSushi]

Yeah I would say it's safe to skip this. The tests related to size limits are pretty notorious for failing in response to environmental changes (including compiler changes).

[decathorpe]

Thanks for confirming!

In this case, I don't think it makes much sense to cfg-gate the test (in addition to the cfg-gate for miri that's already there) since it's dependent on architecture and compiler version - or at least, not yet. I'll just skip it for now.

[BurntSushi]

Yeah I would say it's safe to skip this. The tests related to size limits are pretty notorious for failing in response to environmental changes (including compiler changes).

[decathorpe]

Thanks for confirming!

In this case, I don't think it makes much sense to cfg-gate the test (in addition to the cfg-gate for miri that's already there) since it's dependent on architecture and compiler version - or at least, not yet. I'll just skip it for now.