Branch: refs/heads/davem/re_debug
Home: https://github.com/Perl/perl5
Commit: 676faf69f7f048f041c0569cb843f62e6e605762
https://github.com/Perl/perl5/commit/676faf69f7f048f041c0569cb843f62e6e605762
Author: David Mitchell <[email protected]>
Date: 2025-12-01 (Mon, 01 Dec 2025)
Changed paths:
M regexec.c
Log Message:
-----------
regmatch(): improve savestack ix debugging output
Under
use re Debug => 'STATE';
S_regmatch() produces various bits of debugging output regarding
savestack manipulation; e.g. when the current index is saved; or when
the savestack is popped back to that index on success or failure etc.
Unfortunately that output is patchy and inconsistent. For example it
often talks confusingly about "Setting an EVAL scope" even when an EVAL
hasn't been executed. And it doesn't log all savestack manipulation.
After this commit there is a standard set of debugging messages, such
as:
savestack: snapping ix=14
savestack: regcppush filled in range [14..18)
savestack: regcppop freed in range [14..18)
savestack: freeing in range [10..14)
which are consistently applied.
There should be no change in functionality unless that specific
debugging is enabled.
Commit: 6dee5e6b86cbdbd86719636ad33a5aced48764fe
https://github.com/Perl/perl5/commit/6dee5e6b86cbdbd86719636ad33a5aced48764fe
Author: David Mitchell <[email protected]>
Date: 2025-12-01 (Mon, 01 Dec 2025)
Changed paths:
M regcomp.sym
M regexec.c
M regnodes.h
Log Message:
-----------
regex engine: split EVAL_postponed_AB state
(This commit makes no practical changes in behaviour except for
debugging output.)
Currently, one of the regex engine stack states is EVAL_postponed_AB.
When executing something like /(??{'A'})B/ where A and represent
general subpatterns, the engine executes the eval code, which returns
the string 'A', which is compiled into a subpattern. Then the engine
pushes an EVAL_postponed_AB state and runs the subpattern until it
reaches an END op. Then it pushes *another* EVAL_postponed_AB state and
runs the B part of the pattern until the final END. Then before
returning success, it pops EVAL_postponed_AB off the stack (twice),
executing any cleanup required. Similarly during failure, the
EVAL_postponed_AB_fail action will be executed once or twice (depending
on whether it failed during A or B).
This commit splits that state into two,
EVAL_postponed_A
EVAL_postponed_B
The first is pushed before running A, the second before running B.
The actions currently remain the same and share the same code; i.e. this
commit just does the equivalent of:
- case EVAL_postponed_AB:
+ case EVAL_postponed_A:
+ case EVAL_postponed_B:
... cleanup code ....
But it makes the code easier to understand, makes debugging output
clearer, and will allow in future for the cleanup behaviours to differ
between A and B.
This commit also fixes up a few debugging messages and code comments
which were still referring to 'EVAL_AB', which was renamed to
EVAL_postponed_AB some years ago.
Compare: https://github.com/Perl/perl5/compare/676faf69f7f0%5E...6dee5e6b86cb
To unsubscribe from these emails, change your notification settings at
https://github.com/Perl/perl5/settings/notifications
