-
Notifications
You must be signed in to change notification settings - Fork 417
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
Stack exhausted in the Nfa #98
Comments
@ArtemGr I'm not sure if any recent changes caused this---the recursive nature of |
Now that I look at it more closely, I think the compilation of e.g.,
That way, we eliminate the circuitous path and let each split jump straight to the match. |
Yup, here's the problem, and I definitely touched this in the last few weeks: https://github.com/rust-lang/regex/blob/master/src/compile.rs#L180-L186 |
Looks like regression then. Glad I'm not seeing things ) |
Yup. I should have a fix in some time today. |
Fun little tidbit: |
Cool, thanks! |
rustc appears to have a lot of trouble generating code for the regex `^.{1,2500}`. Presumably it is just too big. The regex is used to test a stack overflow regression in #98. This commit moves the test so that it only runs on dynamic regexes, which can handle it just fine.
So with the latest crates.io regex crates I got this:
The code:
The error seems to happen in the
^.{1,90}
regex.regex 0.1.38; regex_macros 0.1.20; rustc 1.3.0-nightly (faa04a8b9 2015-06-30)
Interesting?
P.S. Decreasing the range of accepted characters (to {1,70}) works, but I wonder why didn't it happened before. Is it a smaller stack in the nightly Rust or a different implementation of the regex?
The text was updated successfully, but these errors were encountered: