Repository navigation
chore(deps): update rust crate fancy-regex to 0.20.0 - #23
Open
renovate[bot] wants to merge 1 commit into
Open
renovate[bot] wants to merge 1 commit into
renovate[bot] wants to merge 1 commit into
Conversation
renovate
Bot
force-pushed
the
renovate/fancy-regex-0.x
branch
from
October 24, 2026 09:23
fe976e5 to
4d42399
Compare
|
Important Review skippedBot user detected. To trigger a single review, invoke the
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
0.18.0→0.20.0Release Notes
fancy-regex/fancy-regex (fancy-regex)
v0.20.0Compare Source
Added
RegexOptionsBuilder::build_delegate_prefilterto disable building the prefilter (#282)RegexOptionsBuilder::start_bytesthat returns the first bytes that can match a pattern so you can build your own prefilter (#282)RegexOptionsBuilder::required_bytesthat returns the required bytes for a pattern to match (#287)RegexOptionsBuilder::max_prog_size/RegexBuilder::max_prog_sizeto cap the number of VM instructions emitted while compiling. Subroutine calls are inlined at compile time, so a self- or mutually-recursive pattern can expand without bound even while the recursion-depth cap is respected; this bounds the emitted instruction vector instead. Exceeding the cap returnsCompileError::PatternTooComplex. Disabled by default. (#298)delegate_size_limitanddelegate_dfa_size_limit. (#286, #309)RegexOptionsBuilder::delegate_dfa_skip_cache_capacity_check/RegexBuilder::delegate_dfa_skip_cache_capacity_check, enabled by default. Setting it tofalsemakes the reverse DFA of a variable-length lookbehind strictly honourdelegate_dfa_size_limit, so a too-small limit becomes a compile error. (#309)ByteSet::is_subsetto test whether one byte set is a subset of another. (#289)Changed
\b,\B,\<,\>) are no longer marked hard outside a lookbehind. regex-automata supports them, so a pattern like\b(?:foo|bar|baz)\bnow compiles to a single delegated engine instead of one branch per alternative — previously it grew linearly with the number of alternatives. They remain hard inside a lookbehind, since regex-automata's reverse DFA can't run a variable-length lookbehind on unicode haystacks. The half-boundary variants and\Zare still always hard. (#311)Regex::capture_namesreports the name for each of them, and named backrefs resolve to the last group with that name (#177)Fixed
delegate_dfa_size_limit(or the default of 2 MiB); for example(?<=\p{L}{99,100})xfailed to compile with default settings. The capacity is now rounded up to the minimum required. Ordinary delegates were not affected because the meta engine falls back to another engine when the lazy DFA cannot be built. (#309)delegate_dfa_size_limitnow sets the lazy DFA cache capacity (hybrid_cache_capacity) as documented, instead of the fully compiled DFA size limit. It had been forwarded to the wrong regex-automata option since the switch from theregexcrate. (#307)\xHHescapes above0x7Fnow match the Unicode codepoint (as UTF-8 bytes) instead of the raw byte, so e.g.\xFFmatchesÿrather than the byte0xFF. In bytes modes the raw byte is matched as before. (#292)(?i)[à-ÿ]), which previously could miss candidate start positions. (#296)^/$and their multi-line variants matching at the start/end of arbitrary-byte haystacks inAsciiandUnicodeBytesbytes modes, where the match position was not a UTF-8 codepoint boundary. (#300)(a)?b(?(1)c)no longer fails to matchb. (#304)(?<=(\w+)\1)xonééx). (#310)v0.19.2Compare Source
Added
leftmost_longestfeature (off by default) that adds a method to theRegexBuilder/RegexOptionsBuilderfor building a VM which would operate in leftmost-longest match mode instead of the regular leftmost-first mode. Useful for POSIX compliance. (#281)Changed
Fixed
capture_names()for a pattern with a zero-repeated named group such as(?<n>a){0}(#275)v0.19.1Compare Source
Added
perf-dfa-fullfeature (off by default, mirroring theregexcrate) that lets regex-automata eagerly build fully compiled dense DFAs for small patterns, for workloads that compile few regexes and match them very heavily (#272)Changed
regex-automatadependency no longer enables thedfa-buildfeature by default. Withdfa-buildenabled,meta::Regexeagerly determinizes a full dense DFA for every small pattern, which dominated build time of simple class-containing patterns (e.g.\b(extern)\s+(crate)compiled ~4x slower than with theregexcrate, which also ships withoutdfa-build); searches use the lazy DFA instead, with no measurable match-time difference (#272)Fixed
optimize_nested_repeatspass could rewrite an optional capture group like(\w+)?into(\w*), causing an unmatched optional group to be reported as an empty match (Some("")) instead ofNone(#276)v0.19.0Compare Source
Added
BytesModeand theRegexInputtrait so the matching and capture APIs can operate on strings or bytes, and allows to opt out of unicode handling if desired (#248)allow_input_assertion_overridesoption was used (#254)RegexBuilder::disallow_empty_match_at_eof_after_newlineto reject empty matches at the end of the haystack following a trailing newline, to match Oniguruma behavior (#247)RegexSetAPI for efficiently matching multiple patterns against the same text (#255)Changed
(?i)(\w+)\1orders of magnitude faster on non-ASCII haystacks. The comparison is now strict fold equality over the captured text's byte-length window: a case-folded prefix of the window no longer counts as a match (previously a substring search could accept one and misalign the match end)Hirinstead of a re-serialized pattern string, andRegexSetparses each pattern once for both of its set-wide engines instead of three times. This reduces compile time and peak compile memory, especially forRegexSetand small easy patternsis_match/find/find_iterandRegexSetcandidate verification allocation-free per call;RegexSet::find_inputno longer allocates at failed candidate positions. Short and repeated matches improve substantially (up to ~30% for small patterns, ~10% forfind_iterover many matches); single very long backtracking runs, where per-run setup is fully amortized anyway, can be a few percent slowerMatches,CaptureMatches,Captures, andSubCaptureMatchesare now generic overRegexInput, which is a breaking change for code that named these types explicitly (#248)(?u)/(?-u)flags are accepted when they agree with the builder configurationFixed
\Goptimizations were applying where they shouldn't, giving wrong results (#256)+only causes possessiveness after?,*or+(#258)Upgrade guide
If you previously stored i.e.
Captures, you would need to change the type toCaptures<str>to get the code to compile.Configuration
📅 Schedule: (UTC)
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.