<regex>: Perform simplified stack unwinding for lookahead assertions when the asserted pattern matches
#5835
+29
−13
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 implements simplified backtracking for the case when the pattern of a lookahead assertion matches. It's kind of the equivalent of #5828 for lookahead assertions, though it's more complicated while being much less practically relevant. But I need this for the next PRs that will greatly reduce the number of allocations the matcher performs.
When the pattern in a lookahead assertion matches, we know that the lookahead assertion as a whole succeeded or failed. We can then mostly skip the stack unwinding up until the stack frame that was pushed at the start of the lookahead assertion, except for the effects these stack frames have on the stack counter, because no stack unwinding opcode translates does any other work when a pattern matched in ECMAScript mode (and ECMAScript is the only regex grammar that supports lookahead assertions). Much of of the work at the end of a lookahead assertion is now also handled when processing the
_N_end_assertnode and no longer when processing the unwinding opcodes_After_assertand_After_neg_assert.You might notice that we could actually avoid the new loop in
_N_end_assertif we kept track of the stack usage counts and the positions of the_After_assertand_After_neg_assertstack frames. But I will have to add a variant of this loop in the PR after the next one anyway, so it doesn't seem worth it to spend much effort on avoiding this loop.