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

regex-automata v0.3.2: test failures on 32-bit architectures #1039

Closed
decathorpe opened this issue Jul 12, 2023 · 4 comments · Fixed by #1040
Closed

regex-automata v0.3.2: test failures on 32-bit architectures #1039

decathorpe opened this issue Jul 12, 2023 · 4 comments · Fixed by #1040
Labels

Comments

@decathorpe
Copy link
Contributor

I'm trying to update the Fedora Linux packages for the regex crate and its dependencies to the latest version, but I'm getting stuck on test failures on 32-bit x86 (i.e. i686-unknown-linux-gnu). Unit tests seem to be fine, but some doctests fail:

failures:
    src/dfa/dense.rs - dfa::dense::Config::determinize_size_limit (line 880)
    src/dfa/dense.rs - dfa::dense::Config::determinize_size_limit (line 913)
    src/util/captures.rs - util::captures::Captures::get_group (line 434)
test result: FAILED. 447 passed; 3 failed; 2 ignored; 0 measured; 0 filtered out; finished in 85.38s

The first two failures produce absolutely gigantic log output on failure, I've pasted the complete output of "cargo test" in a Gist here (though GitHub seems to cut off the content after only 12,000 of 19,000 lines): https://gist.github.com/decathorpe/a5e715d566c5b75838ccd1fbfd4cf4fa

But the gist (pun intended) seems to be:

---- src/dfa/dense.rs - dfa::dense::Config::determinize_size_limit (line 913) stdout ----
Test executable failed (exit status: 101).
stderr:
thread 'main' panicked at 'called `Result::unwrap_err()` on an `Ok` value: dense::DFA(
(... snip 6000 lines of text output ...)

and

---- src/dfa/dense.rs - dfa::dense::Config::determinize_size_limit (line 880) stdout ----
Test executable failed (exit status: 101).
stderr:
thread 'main' panicked at 'called `Result::unwrap_err()` on an `Ok` value: dense::DFA(
(... snip 12000 lines of text output ...)

The third failure is a simple one (numeric literal too large for usize, which is typically only 32-bit integer on 32-bit architectures):

---- src/util/captures.rs - util::captures::Captures::get_group (line 434) stdout ----
error: literal out of range for `usize`
  --> src/util/captures.rs:447:33
   |
16 | assert_eq!(None, caps.get_group(9944060567225171988));
   |                                 ^^^^^^^^^^^^^^^^^^^
   |
   = note: the literal `9944060567225171988` does not fit into the type `usize` whose range is `0..=4294967295`
   = note: `#[deny(overflowing_literals)]` on by default
error: aborting due to previous error
Couldn't compile the test.
@decathorpe
Copy link
Contributor Author

build.log (it appears that uploading the log as an attachment works better)

BurntSushi added a commit that referenced this issue Jul 12, 2023
One of these tests (the captures one) is very specific to 64-bit since
it uses a numeric literal that is bigger than what can be fit into
32 bits.

The other two tests, for determinize_size_limit, are not specific to
64-bit targets but do somewhat depend on the specific memory usages in
play. We could probably find some limits that work for both 32-bit and
64-bit, but since 'cross' doesn't run doc tests, doing this is pretty
annoying. So just ignore the tests.

Fixes #1039
@BurntSushi
Copy link
Member

Thankfully all of these failures are benign. I've put up #1040 to just skip these tests on non-64-bit.

The thornier issue here is that cross doesn't seem to run doc tests, which is why these tests don't cause this repo's CI to fail. We do indeed test on i686-unknown-linux-gnu, but it doesn't capture the (significant number) of doc tests.

@BurntSushi BurntSushi added the bug label Jul 12, 2023
@decathorpe
Copy link
Contributor Author

Thanks for looking into it! I'll just skip those three doctests on 32-bit x86 for now if they're harmless. 👍🏼

@BurntSushi
Copy link
Member

Yup it's basically just a matter of the doc tests exercising the effects of certain limits on heap usage. 32 and 64 bit will vary there and thus the limits just have different effects. And the capture group one is harmless for the reason you point out: it only exercises a case that fails in 64-bit.

BurntSushi added a commit that referenced this issue Jul 12, 2023
One of these tests (the captures one) is very specific to 64-bit since
it uses a numeric literal that is bigger than what can be fit into
32 bits.

The other two tests, for determinize_size_limit, are not specific to
64-bit targets but do somewhat depend on the specific memory usages in
play. We could probably find some limits that work for both 32-bit and
64-bit, but since 'cross' doesn't run doc tests, doing this is pretty
annoying. So just ignore the tests.

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

Successfully merging a pull request may close this issue.

2 participants