Upstream changes:
0.048 2016-02-29 T. R. Wyant
Add option 'strict', like 'use re "strict"'
In the presence of strict(), I opted to set perl_version_introduced
to the version of Perl where the construct became an error.
Parse '\N{}' as no-op.
The previous parse was a character class ('\N') followed by two
literals ('{' and '}'). But perl5238delta said that it had been
ignored up to that time. Starting with 5.23.8 it is an error if 'use
re strict' is in effect.
Quash 'NOT a POSIX class ...' warning under 5.23.8
Add Makefile targets authortest and testcover.
0.047 2016-01-29 T. R. Wyant
Recognize \b{lb}, introduced in 5.23.7. If this is retracted before
5.24, it will be removed outright.
0.046 2016-01-08 T. R. Wyant
Add GitHub repository to mmetadata.
0.045 2015-12-31 T. R. Wyant
Deprecate tokenizer method prior() in favor of
prior_significant_token(). This is not part of the public interface,
so I suppose I could have just slam-dunked it, but ...
Add ability to parse strings as well as regexes
The new functionality is controlled by the new new() argument
'parse', whose permitted values are 'regex' (the default), 'string',
or 'guess'. String parsing, and the 'string' and 'guess' values of
'parse', are experimental.
0.044 2015-12-08 T. R. Wyant
Allow nesting of \Q with \U, \L, and \F
The perlop docs say these nest with each other. Playing with Perl
suggests that \U, \L and \F supersede each other, but thet they as a
group nest with \Q in either order, so that if you specify \Q and
one of the \U, \L, \F group you need two \Es to turn them all back
off.
Restrict recognition of back references in replacement strings to
\number form, since Perl itself does not recognize \g{...} or
\k{...} there.
Recognize postfix dereference if desired. This is controlled by the
Boolean argument 'postderef' passed to PPIx::Regexp->new(). The
default is false, but will become true if postfix dereference
becomes mainstream Perl 5.
Add explain() and supporting methods main_structure() and
in_regex_set(). The explain() method returns a brief explanation of
what the element does.
0.043 2015-11-18 T. R. Wyant
Do not end regex set prematurely on finding '])'
The problem is that '])' can occur within an extended bracketed
character class if it contains grouping parentheses and the last
item in a group is a regular bracketed character class and there is
no white space between the end of the character class and the end of
the group.
Record parse failure if switch condition is unknown
The structure was being reblessed to
PPIx::Regexp::Structure::Unknown, but the number of parse failures
was not being incremented.
Parse \U and friends as meta-characters inside \Q...\E
This turns out to be what Perl itself does, as shown by
$ perl -E 'say qr{\Q\Ufoo}'
Clear error when lexer identifies unknown token. Those who peruse the
changes in this release will see that a bunch of refactoring was
done as part of this.
Parse white space inside bracketed character classes inside extended
bracketed character classes (whew!) as literals, except for the
space character itself and the horizontal tab. This tracks the
corresponding change in Perl 5.23.4. This will be reverted if the
corresponding Perl change does not make it into 5.24.0.
Beginning with version 0.035, PPIx::Regexp was incorrectly reporting
the sense of modifiers when the same token both asserted and negated
modifiers (e.g. '(?x-i:...)'). This release should correct the
problem.
Document policy when Perl changes in such a way that the proper parse
for a regular expression changes. In this case the more modern parse
is preferred.
0.042 2015-10-09 T. R. Wyant
Report error rather than failing when parsing a string consisting
wholly of white space.
Group types were not being recognized if they contained the delimiter
character for the regexp (e.g. in qr<(?\<foo)> the look-behind
assertion was not recognized as such).
Correct mis-parse of ' s///'. Leading white space is supposed to be
acceptable, but the leading whitespace token caused
PPIx::Regexp::Lexer not to recognize the substitution as such.
Tokenizer was failing when the string to be parsed was so bad it was
trying to return the whole thing as a single
PPIx::Regexp::Token::Unknown.
PPIx::Regexp::Dumper now displays a message if a structure is missing
its end delimiter.
RT 107331 Produce parse error in the presence of trailing cruft.
Thanks to Klaus Rindfrey for catching this.
The tokenizer now does a preliminary scan for delimiting brackets
and modifiers. Anything after the modifiers except for white space
is now made into a PPIx::Regexp::Token::Unknown, resulting in a
parse failure being reported. The previous implementation simply
assumed a valid expression, and in the case of the expression in the
ticket blithely mismatched the delimiters and returned a parse
without failures, but which was manifestly bogus.
Tweak documentation in PPIx::Regexp.
db9dcbe13d