In perl.git, the branch yves/revert_skipwhite has been created
<http://perl5.git.perl.org/perl.git/commitdiff/91091a5ce22dfc54e97de3b86c9872365e336a74?hp=0000000000000000000000000000000000000000>
at 91091a5ce22dfc54e97de3b86c9872365e336a74 (commit)
- Log -----------------------------------------------------------------
commit 91091a5ce22dfc54e97de3b86c9872365e336a74
Author: Yves Orton <[email protected]>
Date: Sun Feb 24 23:09:23 2013 +0100
simplify some of the logic related to the new PMf_SPLIT flags by
reorganizing bits
M op.h
M op_reg_common.h
M pp_ctl.c
M regen/regcomp.pl
M regexp.h
M regnodes.h
commit ba38b0b9069b44964053e3595ed1bff40c88cd53
Author: Yves Orton <[email protected]>
Date: Sun Feb 24 21:38:30 2013 +0100
make it so that run time patterns can trigger SKIPWHITE/WHITE
This probably neutralizes RT #94490.
Prior to this patch the special RXf_SKIPWHITE behavior of
split(" ", $thing)
was only available if Perl could resolve the first argument to
split at compile time, meaning under various arcane situations.
This manifested as oddities like
my $delim = $cond ? " " : qr/\s+/;
split $delim, $string;
and
split $cond ? " ", qr/\s+/, $string
not behaving the same as:
($cond ? split(" ", $string) : split(/\s+/, $string))
which isn't very convenient.
This patch changes this by adding a new flag to the op_pmflags,
PMf_SPLIT which enabled pp_regcomp() to know whether it was called
as part of split, which would allow the RXf_SPLIT to be passed into
the run time compilation. We could use optree inspection for this instead,
but a follow up patch will reoganize things so that the extra flags
works with stuff we already have to do.
Working on this revealed a secondary issue: when we check if we need to
recompile a pattern in pp_regcomp() we did not check the flags to see
if they are the same. So doing something like this:
split $x ? " " : qr/ /, $string;
repeatedly would never exhibit the " " behavior once the qr/ / behavior
was exhibited, as the two patterns would have the same pattern and
length, despite having different flags. I added a flag test to the cache
logic, but I doubt it is sufficient: flags get turned on as we compile,
and even maybe turned off, so a simple comparison doesnt really work.
For now we ensure that expected extflags are all on in the cached
regex. I'm not sure what to do about this other than store the original
extflags in the regex (in addition to the actual extflags).
It is possible that this problem affects other cases where we have
flags that affect compilation that are not part of the compiled pattern.
Which makes me think what we really need is a magic pattern (*SKIPWHITE)
which acts like \s+ but triggers the SKIPWHITE behavior (split ' ') from
a regexp. If we pretended we compiled a (*SKIPWHITE) then we would be
able to tell the branches apart in split $x ? " " : qr/ / by comparing
the pattern alone. (Something like that).
M op.c
M op.h
M pp_ctl.c
M regcomp.c
M t/op/split.t
commit 2e1d4b8182209591c96f7f417b7985a69e1f1bd7
Author: Yves Orton <[email protected]>
Date: Sun Feb 24 15:33:19 2013 +0100
Revert "[perl #94490] const fold should not trigger special split " ""
Revert, with minor changes and some merges:
5255171e6cd0accee6f76ea2980e32b3b5b8e171
The reverted patch was meant to make:
split( 0 || " ", $thing ) #1
consistent with
my $x=0; split( $x || " ", $thing ) #2
and not with
split( " ", $thing ) #3
This was reverted because it broke C<split("\x{20}", $thing)>, and
because one might argue that is not that #1 does the wrong thing,
but rather that the behavior of #2 that is wrong. In other words
we might expect that all three should behave the same as #3, and
that instead of "fixing" the behavior of #1 to be like #2, we should
really fix the behavior of #2 to behave like #3.
Also, it doesn't make sense to move this further from the regex
engine. We really want the regex engine to decide this stuff itself,
otherwise split " ", ... wouldn't work properly with an alternate
engine. (Imagine we add a special regexp meta pattern that behaves
the same as " " does in a split /.../. For instance we might make
split /(*SPLITWHITE)/ trigger the same behavior as split " ".
Anyway, it can wait until after 5.18 to figure it out. The op logic
involved in this stuff makes my head spin.
M dist/B-Deparse/Deparse.pm
M op.c
M op.h
M pp.c
M regcomp.c
M regexp.h
M t/op/split.t
commit adc5574106acf8126e2335fdbf6f496de254a332
Author: Yves Orton <[email protected]>
Date: Sat Feb 23 13:56:19 2013 +0100
Revert "Define RXf_SPLIT and RXf_SKIPWHITE as 0"
This effectively reverts commit cccd1425414e6518c1fc8b7bcaccfb119320c513.
We dont want to get rid of these vars, and it turns out that
RXf_SEEN_LOOKBEHIND is used only in the same situation of the new
RXf_MODIFIES_VARS. So I have renamed RXf_SEEN_LOOKBEHIND to
RXf_NO_INPLACE_SUBST, and then instead of using two vars we use
only the one. Which in turn allows RXf_SPLIT and RXf_SKIPWHITE to
have their bits back.
This is in preparation for reverting another patch in this sequence.
M dump.c
M pod/perlreapi.pod
M pp_hot.c
M regcomp.c
M regexp.h
M regnodes.h
-----------------------------------------------------------------------
--
Perl5 Master Repository
