fix instances of exponential backtracking found by recheck #5144
Conversation
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## master #5144 +/- ##
==========================================
- Coverage 86.94% 86.68% -0.27%
==========================================
Files 560 560
Lines 44220 44199 -21
Branches 6854 6850 -4
==========================================
- Hits 38446 38312 -134
- Misses 5774 5887 +113
Flags with carried forward coverage won't be shown. Click here to find out more.
☔ View full report in Codecov by Sentry. |
31199c9 to
fdea2bb
Compare
| checkBacktracking(tokenizer); | ||
| // TODO this is too slow to run in regular tests | ||
| // checkBacktracking(tokenizer); |
There was a problem hiding this comment.
checkBacktracking function implementation did not change - why do we need to comment it out? checkBacktrackingWithRecheck is what seems to be slow based on your comments, and it's not used anywhere, so we don't need to comment out checkBacktracking as well.
There was a problem hiding this comment.
checkBacktracking was my naive attempt to implement something similar to recheck, when it was not available yet. It had too many false positives and was needlessly cluttering test output with warnings that no one was reading. We probably should remove it entirely.
0d34f5b to
9dd82df
Compare
https://www.npmjs.com/package/recheck is able to find slow regexps in many cases. It helped to find two instances of such behavior. Unfortunately it is not fast enough to run after each pull request, so i've commented out the test code, but perhaps it is worth to add a separate workflow to run recheck only for changed mode files.