On Wed Nov 16 12:26:43 2011, MJGARDNER wrote:
Show quoted text> PPIx::Regexp doesn't report modifiers applied by the Perl 5.14 "use re
> '/flags'" pragma, e.g. "use re '/xms'". This is related to RT#72151
> reported on Perl::Critic, but I'm adding the bug here so it's documented
> in the right place. I've attached a small test script.
Thank you for your report.
I debated about requeueing 72151 to the PPIx-Regexp queue, and then
shoving it back in the Perl-Critic queue once PPIx-Regexp was up to
snuff, but I was afraid it would get lost in the shuffle. But the Right
Thing To Do is have a ticket against PPIx-Regexp, so now there is one.
That said, PPIx::Regexp is a static analyzer, and will never detect
implicit modifiers in the script where it is running. But even though
that makes this technically a reject, in context the ticket is needed,
and will keep it open at least until I think the PPIx::Regexp part of
the job is done.
The implementation path being taken is to:
1) Provide a way to tell PPIx::Regexp what implicit modifiers are in
effect at the time the object is instantiated;
2) Once this exists, have Perl::Critic figure out what is in scope at
the regular expression under analysis, and feed those to PPIx::Regexp.
Because I have committed to PPIx::Regexp being round-trip safe, the
default modifiers can never show up in $re->modifiers(). That object
_must_ represent the modifiers actually present in the regular
expression. So what has actually happened is that there is an argument
to new() to feed in the required defaults (and the smarts to take a
bunch of them and figure out what the defaults actually are), and a
separate method to say whether a given modifier is asserted, whether it
is explicit or implicit.
The PPIx::Regexp part of the planned functionality is already mostly in
PPIx::Regexp 0.021_10 - at any rate the interface is there. The 0.021_11
release was fixing a misunderstanding (spelled b-u-g) about what happens
when you say 'no re /u' (or any other of the new match semantic
modifiers). My original plan was to wait a week after the most-recent
development release, and then put out version 0.022. But CPAN testers
has yet to record any tests against either of the development releases,
so I will just make a judgment call the middle of next week about how
thoroughly it has all been tested, and release when I'm happy.
The Perl::Critic modifications based on the PPIx::Regexp modifications
are also already coded up, but I am not going to commit anything to the
SVN repository until the production PPIx::Regexp is out there.
The Perl::Critic changes involve a new method on Perl::Critic::Document
to find out if element Bravo is in-scope from element Alpha. This will
benefit other tickets in the queue, and it goes on the document in case
caching becomes necessary. The other change is machinery in the
ppix_regexp_from_element() method to find all the relevant 'use re'
elements, and spoon-feed them to PPIx::Regexp->new(). At the outset I
was worried about wasted motion, but the ppix_regexp_from_element()
method is cached, so you will only grovel through the document once for
any regular expression no matter how many policies want to take a look
at it.
Tom
