Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
decathorpe opened this issue Oct 4, 2024 · 2 comments

Comments

@decathorpe
Copy link
Contributor

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
Copy link
Member

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
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants