You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add grammar-based differential fuzzing for CometRegex #5811
PR #5415 introduces CometRegex, a conservative plan-time analyzer that allows a restricted subset of literal Java regex patterns to use native Rust rlike execution by default.
The current parity suite uses a fixed corpus. This covers patterns we anticipated, but it may not detect an unexpected combination of otherwise admitted constructs. The safety property is that every pattern admitted by CometRegex must have the same matching behavior in Java's java.util.regex engine and Comet's native Rust regex kernel.
Describe the potential solution
Add a deterministic grammar-based generator that produces both admitted and rejected regex patterns, including combinations of:
printable ASCII literals;
character classes, ranges, negation, and escaped metacharacters;
concatenation and alternation;
capturing and non-capturing groups;
greedy and counted quantifiers;
constructs that CometRegex is expected to reject.
For every generated pattern admitted by CometRegex, compare Java Pattern.matcher(subject).find() with the actual native Rust rlike result.
Generated subjects should include ASCII and non-ASCII strings, empty strings, newlines, control characters, exotic whitespace, supplementary Unicode code points, and NULL where applicable.
The generator should use a reproducible seed and report the seed, pattern, subject, and both results on failure. If the test is too expensive for every pull request, it could run in a nightly workflow.
MVP differential fuzzer: a small grammar generator, admit/reject assertions, fixed seeds and subjects, Java vs. native rlike comparison, and reproducible failure reports.
Coverage expansion and CI: broader grammar and subject coverage, depth/size boundary cases, statistics, and nightly CI integration.
The first PR will deliver a working end-to-end fuzzer and verify that comparisons actually exercise the native path. The second will build on it to expand coverage and support regular runs.
Activity
sam-1112 commentedon Nov 11, 2026
take
sam-1112 commentedon Nov 11, 2026
I’ll implement this in two PRs:
rlikecomparison, and reproducible failure reports.The first PR will deliver a working end-to-end fuzzer and verify that comparisons actually exercise the native path. The second will build on it to expand coverage and support regular runs.