Repository navigation
Fix NUL collisions in runtime cache keys - #152
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
More details
The structural keys keep literal-NUL patterns distinct from option-bearing compilations across runtime caches, including explicit user-key validation and mutable matcher reconstruction. The completed static review identified no reportable regression.
🤖 Bits Code Review · Commit 35724ba
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #152 +/- ##
=======================================
Coverage 85.0% 85.0%
Complexity 1 1
=======================================
Files 168 168
Lines 49878 49882 +4
Branches 7594 7592 -2
=======================================
+ Hits 42409 42417 +8
+ Misses 5466 5464 -2
+ Partials 2003 2001 -2
... and 3 files with indirect coverage changes Continue to review full report in Codecov by Harness.
🚀 New features to boost your workflow:
|
What does this PR do?
Replaces NUL-delimited string cache identities with an immutable structural key containing the
source pattern, flags, and enabled
ReggieOptionvalues.The structural key is used consistently by the level-1 matcher cache and all runtime
engine/factory caches. Annotation-stub backtracker entries now have a separate string-keyed cache,
matching the existing PikeVM stub/runtime separation.
Regression coverage exercises the formerly colliding identities in both call orders through:
cached(key, pattern, options)validation.Motivation
NUL is a supported pattern literal, so concatenating option names to the pattern with a NUL
separator is not injective. For example, these two identities previously produced the same engine
key:
That could return a matcher compiled for a different pattern instead of compiling independently or
throwing for reuse of an explicit user key.
This follows up the finding on #149:
#149 (comment)
Knowledge constraint consumed:
kb/find-nul-pattern-truncation— pattern-side NUL remains validdata and must not be treated as a sentinel or separator.
Related Issue(s)
Follow-up to #149.
Change Type
Checklist
./gradlew build)Performance Impact
No matching-path impact is expected. Compilation-cache lookup now hashes a small immutable value
object instead of a delimiter-encoded string. Default and non-default option identities use the
same structural representation.
Additional Notes
Verification completed:
:reggie-runtime:testsuite (3,667 tests);./gradlew build;:reggie-integration-tests:test;spotlessApply/spotlessCheck;git diff --check.