perl.git
6 years agoremove code for non-core builds and "modernize"
Tony Cook [Sat, 13 Apr 2013 05:05:33 +0000 (15:05 +1000)] 
remove code for non-core builds and "modernize"

6 years agotest that perl headers don't introduce external references
Tony Cook [Sat, 13 Apr 2013 04:49:26 +0000 (14:49 +1000)] 
test that perl headers don't introduce external references

This is as close as possible to the original Time::HiRes probe code,
further commits will clean that up.

[perl #116989]

[Amended from Tony's original to add -DPERL_NO_INLINE_FUNCTIONS]

6 years agoIf PERL_NO_INLINE_FUNCTIONS is defined, don't include "inline.h"
Nicholas Clark [Fri, 26 Apr 2013 10:18:41 +0000 (12:18 +0200)] 
If PERL_NO_INLINE_FUNCTIONS is defined, don't include "inline.h"

This permits test code to include the perl headers for definitions without
creating a link dependency on the perl library (which may not exist yet).

Some of the static inline functions in inline.h reference functions in the
perl object files, and some compilers aren't smart enough to eliminate
unused static inline functions, hence including the inline.h in probe code
can cause link errors even though the probe code uses none of the functions
it declares. When probing, a failed link is taken as meaning that the
probed-for function is not present, as the assumption is that the link fails
because of it. Hence other causes of link failures cause the probing code to
generate incorrect results, and action (and bugs) at a distance.

6 years agoRevert "Change the warning for $* to add ", and will become a syntax error"."
Nicholas Clark [Mon, 8 Apr 2013 15:05:11 +0000 (17:05 +0200)] 
Revert "Change the warning for $* to add ", and will become a syntax error"."

This reverts commit 53213d38f22e9356f489162e494d2ffa46ec2ca2.

Conflicts:

pod/perldelta.pod

6 years agoRevert "Add a deprecation warning for all uses of @*, %*, &* and **."
Nicholas Clark [Mon, 8 Apr 2013 14:53:47 +0000 (16:53 +0200)] 
Revert "Add a deprecation warning for all uses of @*, %*, &* and **."

This reverts commit 982110e06e40aad7a538cb788327cca8aaabce22.

Conflicts:

pod/perldelta.pod

6 years agoDeprecate spaces/comments in some regex tokens
Karl Williamson [Tue, 23 Apr 2013 19:39:35 +0000 (13:39 -0600)] 
Deprecate spaces/comments in some regex tokens

This commit deprecates having space/comments between the first two
characters of regular expression forms '(*VERB:ARG)' and '(?...)'.
That is, the '(' should be immediately be followed by the '*' or '?'.
Previously, things like:

   qr/((?# This is a comment in the middle of a token)?:foo)/

were silently accepted.

The problem is that during regex parsing, the '(' is seen, and the input
pointer advanced, skipping comments and, under /x, white space, without
regard to whether the left parenthesis is part of a bigger token or not.
S_reg() handles the parsing of what comes next in the input, and it
just assumes that the first character it sees is the one that
immediately followed the input parenthesis.

Since the parenthesis may or may not be a part of a bigger token, and
the current structure of handling things, I don't see an elegant way to
fix this.  What I did is flag the single call to S_reg() where this
could be an issue, and have S_reg check for for adjacency if the
parenthesis is part of a bigger token, and if so, warn if not-adjacent.

6 years agolib/utf8_heavy.pl: Fix separated '(?' token
Karl Williamson [Tue, 23 Apr 2013 21:06:57 +0000 (15:06 -0600)] 
lib/utf8_heavy.pl: Fix separated '(?' token

The next commit will warn when these aren't adjacent

6 years agoPATCH: [perl #117327]: Sequence (?#...) not recognized in regex
Karl Williamson [Thu, 2 May 2013 01:01:29 +0000 (19:01 -0600)] 
PATCH: [perl #117327]: Sequence (?#...) not recognized in regex

This reverts commit 504858073fe16afb61d66a8b6748851780e51432, which
was made under the erroneous belief that certain code was unreachable.
This code appears to be reachable, however, only if the input has
a 2-character lexical token split by space or a comment.  The token
should be indivisible, and was accepted only through an accident of
implementation.  A later commit will deprecate splitting it, with the
view of eventually making splitting it a fatal error.  In the meantime,
though, this reverts to the original behavior, and adds a (temporary)
test to verify that.

6 years agoreg_mesg.t: Turn off regexp warns along with deprecated
Karl Williamson [Thu, 2 May 2013 00:31:34 +0000 (18:31 -0600)] 
reg_mesg.t: Turn off regexp warns along with deprecated

Some warnings are both regexp and deprecated.  To test that they are
under control of 'deprecated', it is necessary to turn off both
categories.  We currently don't test that they are also under 'regexp'
control

6 years agoCarp: add a test for top-of-stack longmess
Ricardo Signes [Wed, 1 May 2013 16:54:10 +0000 (12:54 -0400)] 
Carp: add a test for top-of-stack longmess

6 years agoCarp: distinguish deleted stash from top of stack
Ricardo Signes [Wed, 1 May 2013 15:41:50 +0000 (11:41 -0400)] 
Carp: distinguish deleted stash from top of stack

The change to work with deleted stashes broke the behavior of Carp
at the top of the stack.

This change distinguishes between the two cases: at the top of the
stack, caller(1) returns ().  If the stash has been deleted, it
returns a populated list with an undefined package name.  The test
used here is to check for a defined line number, which should be
sufficient.

6 years agoI cannot find shorter URL's
H.Merijn Brand [Wed, 1 May 2013 10:17:20 +0000 (12:17 +0200)] 
I cannot find shorter URL's

6 years agoUpdate HP-UX readme
H.Merijn Brand [Wed, 1 May 2013 09:08:37 +0000 (11:08 +0200)] 
Update HP-UX readme

The porting center cannot be said to ship recent perl when 5.18.0 is about
to be released and they just have 5.10.1 available. Trying "very hard" now
sounds like a huge overstatement. Sadly.

Telling what modules were included in the first public perl port from HP is
like digging up corpses.

HP-UX 11.31 has now EOL set to 2022. I've updated all other EOL info too.

6 years agoRemove a comment made obsolete by commit 213f370f28504f3a.
Nicholas Clark [Mon, 29 Apr 2013 14:03:23 +0000 (16:03 +0200)] 
Remove a comment made obsolete by commit 213f370f28504f3a.

Commit 213f370f28504f3a enabled running tests in t/op/*.t in parallel. It
should also have removed the comment saying that this would be nice to have.

6 years agoupdate known_pod_issues.dat to account for the README.macosx change
Tony Cook [Mon, 29 Apr 2013 07:50:15 +0000 (17:50 +1000)] 
update known_pod_issues.dat to account for the README.macosx change

The insanely long directory name gave us an extra verbatim line over
79 characters.

6 years agoupdating README.macosx to reflect current systems.
Breno G. de Oliveira [Mon, 29 Apr 2013 05:05:17 +0000 (02:05 -0300)] 
updating README.macosx to reflect current systems.

6 years ago[perl #117743] don't warn on $@ = undef; die;
Tony Cook [Thu, 25 Apr 2013 23:56:58 +0000 (09:56 +1000)] 
[perl #117743] don't warn on $@ = undef; die;

and fix the test that's meant to detect this bug.

6 years ago[perl #117607] don't crash on: use strict; $foo; &CORE::lc
Tony Cook [Fri, 26 Apr 2013 01:57:36 +0000 (11:57 +1000)] 
[perl #117607] don't crash on: use strict; $foo; &CORE::lc

6 years ago[perl #117607] don't use a CV after it's been freed
Tony Cook [Thu, 25 Apr 2013 08:27:09 +0000 (18:27 +1000)] 
[perl #117607] don't use a CV after it's been freed

6 years ago[perl #117607] TODO test for \&CORE::lc in error context
Tony Cook [Thu, 25 Apr 2013 08:10:10 +0000 (18:10 +1000)] 
[perl #117607] TODO test for \&CORE::lc in error context

The original sample was:

BEGIN {
$^H |= 0x00000400; # strict vars
}
# Undeclared variable here
sub foo { return $anyvar; }
# Any CORE:: here
sub bar { \&CORE::lc }

simplified to:

BEGIN {
$^H |= 0x00000400; # strict vars
}
$anyvar;
&CORE::lc;

but it occurs for any compile-time error that doesn't abort compilation,
such as:

$foo/; \&CORE::lc

6 years agot/op/smartkve.t: single-quote some eval stuff
David Mitchell [Wed, 24 Apr 2013 16:57:04 +0000 (17:57 +0100)] 
t/op/smartkve.t: single-quote some eval stuff

Three tests were wrong because they incorrectly double- rather than
single-quoted an eval string like

    eval "keys $hash ...."

Since the tests were supposed to generate syntax errors anyway it didn't
show up. However, the $hash ref was being expanded to HASH(0x......)
and on some platform / compiler permutations it would generate some
mysterious

    Hexadecimal number > 0xffffffff non-portable

warnings.

6 years agomake qr/(?{ __SUB__ })/ safe
David Mitchell [Wed, 24 Apr 2013 15:29:42 +0000 (16:29 +0100)] 
make qr/(?{ __SUB__ })/ safe

(See RT #113928)

Formerly, __SUB__ within a code block within a qr// returned
a pointer to the "hidden" anon CV that implements the qr// closure. Since
this was never designed to be called directly, it would SEGV if you tried.

The easiest way to make this safe is to skip any CXt_SUB frames that
are marked as CXp_SUB_RE: i.e. skip any subs that are there just to
execute code blocks. For a qr//, this means that we return the sub which
the pattern match is embedded in.

Also, document the behaviour of __SUB__ within code blocks as being
subject to change. It could be argued for example that in these cases it
should return undef. But with the 5.18.0 release a month or two away, just
make it safe for now, and revisit the semantics later if necessary.

6 years agofix caller with re_evals.
David Mitchell [Wed, 24 Apr 2013 13:41:33 +0000 (14:41 +0100)] 
fix caller with re_evals.

(See RT #113928)

In code like

    sub foo {  /A(?{ bar; caller(); }B/; }

the regex /A(?{B})C/ is, from a scope point of view, supposed to
be compiled and executed as:

    /A/ && do { B } && /C/;

i.e. the code block in B is part of the same sub as the code surrounding
the regex. Thus the result of caller() above should see the caller as
whoever called foo.

Due to an implementation detail, we actually push a hidden extra
sub CX before calling the pattern. This detail was leaking when caller()
was used. Fux it so that it ignores this extra context frame.

Conversely, for a qr//, that *is* supposed to be seen as an extra level
of anonymous sub, so add tests to ensure that is so.
i.e.

    $r = qr/...(?{code}).../
    /...$r.../

is supposed to behave like

    $r = sub { code };
    $r->();

6 years agoPUSH_MULTICALL_WITHDEPTH becomes ..._FLAGS
David Mitchell [Wed, 24 Apr 2013 10:14:39 +0000 (11:14 +0100)] 
PUSH_MULTICALL_WITHDEPTH becomes ..._FLAGS

Two non-API macros were added with 5.17.1 to support the more
complex calling conventions required by /({})/ code blocks:

    PUSH_MULTICALL_WITHDEPTH(the_cv, depth)
    CHANGE_MULTICALL_WITHDEPTH(the_cv, depth)

which allowed us to do the same as the API versions, but to optionally
not increment the caller depth, and to change the current CV.

Replace these with two new macros:

    PUSH_MULTICALL_FLAGS(the_cv, flags)
    CHANGE_MULTICALL_FLAGS(the_cv, flags)

which instead allow us to set extra flags in cx->cx_type.
The depth increment skip is handled by the new CXp_SUB_RE_FAKE flag,
and all (?{}) calls set the new CXp_SUB_RE flag.

These two new flags will shortly allow us to change how caller() and
__SUB__ handle code blocks.

6 years agomove Perl_ck_warner() before unwind [perl #113794]
Zefram [Tue, 23 Apr 2013 14:30:46 +0000 (10:30 -0400)] 
move Perl_ck_warner() before unwind [perl #113794]

Indeed. The Perl_ck_warner() call in die_unwind() used to happen
before unwinding, so would be affected by the lexical warning state
at the die() site. Now it happens after unwinding, so takes the
lexical warning state at the catching site. I don't have a clear
idea of which behaviour is more correct. t/op/die_keeperr.t, which
was introduced as part of my exception handling changes, is actually
testing for the catching-site criterion, but that's not asserting
that the criterion should be that.  The documentation speaks of "no
warnings 'misc'", but doesn't say which lexical scope matters.

Assuming we want to revert this change, the easy fix is to move the
conditional Perl_ck_warner() back to before unwinding. A more
difficult way would be to determine the disposition of the warning
before unwinding and then warn in the required manner after
unwinding.  I see no compelling reason to warn after unwinding
rather than before, so just moving the warning code should be fine.

Note from the committer: This patch was supplied by Zefram in
https://rt.perl.org/rt3/Ticket/Display.html?id=113794#txn-1204749
with a note that some extra work was required for
ext/XS-APItest/t/call.t before the job was done.  Ricardo Signes
applied this patch and followed Zefram's lead in patching
ext/XS-APItest/t/call.t without being 100% certain that this was
what was meant.  This commit was then submitted for review.

6 years agoPOD nitpicks.
SHIRAKATA Kentaro [Tue, 23 Apr 2013 08:34:07 +0000 (17:34 +0900)] 
POD nitpicks.

Also, rebreak some verbatim lines to avoid porting error.
Update known_pod_issues.dat.

6 years agoAdd the deprecation data to Maintainers.pl
Chris 'BinGOs' Williams [Tue, 23 Apr 2013 15:20:52 +0000 (16:20 +0100)] 
Add the deprecation data to Maintainers.pl

6 years agoAvoid use of $(...) as backticks in SH code
Eric Brine [Fri, 19 Apr 2013 03:57:54 +0000 (20:57 -0700)] 
Avoid use of $(...) as backticks in SH code

Avoid use of $(...) as backticks in SH code as it is not supported
by all /bin/sh. RT#115708.

6 years agoInclude deprecations for v5.17.10 and v5.17.11 in Module::CoreList
Chris 'BinGOs' Williams [Tue, 23 Apr 2013 10:48:35 +0000 (11:48 +0100)] 
Include deprecations for v5.17.10 and v5.17.11 in Module::CoreList

This will probably resolve [perl #117711]

6 years agoSpelling typo in perllocale
Rafael Garcia-Suarez [Tue, 23 Apr 2013 11:08:43 +0000 (13:08 +0200)] 
Spelling typo in perllocale

6 years agoperl-5.17.11 fails to build with x64 mingw64 (gcc-4.7.0)
Sisyphus [Sun, 21 Apr 2013 10:41:23 +0000 (03:41 -0700)] 
perl-5.17.11 fails to build with x64 mingw64 (gcc-4.7.0)

# New Ticket Created by  "Sisyphus"
# Please include the string:  [perl #117687]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=117687 >

This is a bug report for perl from sisyphus@OWNER-PC311012,
generated with the help of perlbug 1.39 running under perl 5.17.11.

-----------------------------------------------------------------
[Please describe your issue here]

This is essentially a repeat of a post sent to p5p on March 24 2013
titled "[Win32] perl-5.17.10 fails to build with x64 mingw64 (gcc-4.7.0)"

The issue still exists for 5.17.11 (for me).

The error I get is:

In file included from ../hv.h:570:0,
                 from ../perl.h:3480,
                 from perllib.c:10:
../hv_func.h: In function 'U32 S_perl_hash_murmur3(const unsigned char*,
const u
nsigned char*, STRLEN)':
../hv_func.h:395:20: error: cast from 'const unsigned char*' to 'long int'
loses
precision [-fpermissive]

Signed-off-by: Chris 'BinGOs' Williams <chris@bingosnet.co.uk>
6 years agoBump the perl version in various places for 5.17.12
Ricardo Signes [Sun, 21 Apr 2013 01:08:14 +0000 (21:08 -0400)] 
Bump the perl version in various places for 5.17.12

...even though it should not get released

6 years agoMerge branch 'release-5.17.11' into blead
Ricardo Signes [Sun, 21 Apr 2013 00:57:26 +0000 (20:57 -0400)] 
Merge branch 'release-5.17.11' into blead

6 years agoperlapi.pod: Clarify character classification macros
Karl Williamson [Sat, 20 Apr 2013 17:39:28 +0000 (11:39 -0600)] 
perlapi.pod: Clarify character classification macros

The language was confusing, and this also fixes a typo.

6 years ago[MERGE] Handle /@a/ array expansion within regex engine
David Mitchell [Sat, 20 Apr 2013 16:31:19 +0000 (17:31 +0100)] 
[MERGE] Handle /@a/ array expansion within regex engine

This series of commits reorganises the code that concatenates and processes
the list of args in a run-time regular expression (fixing some bugs along
the way); then, most significantly, defers flattening and concatting an
array in /...@a.../ until the regex engine: so the engine gets to process
the individual elements of @a rather than being presented with a just a
final concatenated string. This allows us to improve the handling of code
blocks and overloading of the individual array elements.

Fixes RT #115004.

6 years agoHandle /@a/ array expansion within regex engine
David Mitchell [Wed, 17 Apr 2013 16:51:16 +0000 (17:51 +0100)] 
Handle /@a/ array expansion within regex engine

Previously /a@{b}c/ would be parsed as

    regcomp('a', join($", @b), 'c')

This means that the array was flattened and its contents stringified before
hitting the regex engine.

Change it so that it is parsed as

    regcomp('a', @b, 'c')

(but where the array isn't flattened, but rather just the AV itself is
pushed onto the stack, c.f. push @b, ....).

This means that the regex engine itself can process any qr// objects
within the array, and correctly extract out any previously-compiled
code blocks (thus preserving the correct closure behaviour). This is
an improvement on 5.16.x behaviour, and brings it into line with the
newish 5.17.x behaviour for *scalar* vars where they happen to hold
regex objects.

It also fixes a regression from 5.16.x, which meant that you suddenly
needed a 'use re eval' in scope if any of the elements of the array were
a qr// object with code blocks (RT #115004).

It also means that 'qr' overloading is now handled within interpolated
arrays as well as scalars:

    use overload 'qr' => sub { return  qr/a/ };
    my $o = bless [];
    my @a = ($o);
    "a" =~ /^$o$/; # always worked
    "a" =~ /^@a$/; # now works too

6 years agoS_pat_upgrade_to_utf8(): add num_code_blocks arg
David Mitchell [Thu, 18 Apr 2013 14:42:35 +0000 (15:42 +0100)] 
S_pat_upgrade_to_utf8(): add num_code_blocks arg

This function was added a few commits ago in this branch. It's intended
to upgrade a pattern string to utf8, while simultaneously adjusting the
start/end byte indices of any code blocks. In two of the three places
it is called from, all code blocks will already have been processed,
so the number of code blocks equals pRExC_state->num_code_blocks.
In the third place however (S_concat_pat), not all code blocks have yet
been processed, so using num_code_blocks causes us to fall off the end of
the index array.

Add an extra arg to S_pat_upgrade_to_utf8() to tell it how many code
blocks exist so far.

6 years agoPerl_re_op_compile() re-indent code
David Mitchell [Tue, 16 Apr 2013 11:36:04 +0000 (12:36 +0100)] 
Perl_re_op_compile() re-indent code

Re-indent code after the previous commit removed a block scope.
Only whitespace changes.

6 years agore_op_compile: eliminate a local var and scope
David Mitchell [Tue, 16 Apr 2013 11:12:21 +0000 (12:12 +0100)] 
re_op_compile: eliminate a local var and scope

Eliminate a local var and the block scope it is declared in
(There should be no functional changes).

Re-indenting will be in the next commit.

6 years agocombine regex concat overload loops
David Mitchell [Tue, 16 Apr 2013 10:34:54 +0000 (11:34 +0100)] 
combine regex concat overload loops

Currently when the components of a runtime regex (e.g. the "a", $x, "-"
in /a$x-/) are concatenated into a single pattern string, the handling of
magic and various types of overloading is done within two separate loops:
(in perlish pseudocode):

    foreach (@arg) {
        SvGETMAGIC($_);
        apply 'qr' overloading to $_;
    }
    foreach (@arg) {
        $pat .= $_, allowing for '.' and '""' overloading;
    }

This commit changes it to:

    foreach (@arg) {
        SvGETMAGIC($_);
        apply 'qr' overloading to $_;
        $pat .= $_, allowing for '.' and '""' overloading;
    }

Note that this is in theory a user-visible change in behaviour, since
the order in which various perl-level tie and overload functions get
called may change. But that was just a quirk of the current
implementation, rather than a documented feature.

6 years agoPerl_re_op_compile(): extract conatting code
David Mitchell [Tue, 16 Apr 2013 09:57:10 +0000 (10:57 +0100)] 
Perl_re_op_compile(): extract conatting code

Extract out the big chunk of code that concatenates the components
of a pattern string, into the new static function S_concat_pat().

As well as being tidier, it will shortly allow us to recursively
concatenate, and allow us to directly interpolate arrays such as
/@foo/, rather than relying on pp_join to do it for us.

6 years agoPerl_re_op_compile(): handle utf8 concating better
David Mitchell [Mon, 15 Apr 2013 16:18:30 +0000 (17:18 +0100)] 
Perl_re_op_compile(): handle utf8 concating better

When concatting the list of arguments together to form a final pattern
string, the code formerly did a quick scan of all the args first, and
if any of them were SvUTF8, it set the (empty) destination string to UTF8
before concatting all the individual args. This avoided the pattern
getting upgraded to utf8 halfway through, and thus the indices for code
blocks becoming invalid.

However this was not 100% reliable because, as an "XXX" code comment of
mine pointed out, when overloading is involved it is possible for an arg
to appear initially not to be utf8, but to be utf8 when its value is
finally accessed. This results an obscure bug (as shown in the test added
for this commit), where literal /(?{code})/ still required 'use re
"eval"'.

The fix for this is to instead adjust the code block indices on the fly
if the pattern string happens to get upgraded to utf8. This is easy(er)
now that we have the new S_pat_upgrade_to_utf8() function.

As well as fixing the bug, this also simplifies the main concat loop in
the code, which will make it easier to handle interpolating arrays (e.g.
/@foo/) when we move the interpolation from the join op into the regex
engine itself shortly.

6 years agoPerl_re_op_compile: eliminate clunky if (0) {}
David Mitchell [Mon, 15 Apr 2013 13:41:10 +0000 (14:41 +0100)] 
Perl_re_op_compile: eliminate clunky if (0) {}

There was a bit of code that did

    if (0) {
      redo_first_pass:
        ...foo...;
    }

to allow us to jump back and repeat the first pass, doing some extra stuff
the second time round. Since foo has now been abstracted into a separate
function, we can instead call it each time directly before jumping,
allowing us to remove the ugly if (0).

6 years agoPerl_re_op_compile(): eliminate xend var
David Mitchell [Mon, 15 Apr 2013 13:35:23 +0000 (14:35 +0100)] 
Perl_re_op_compile(): eliminate xend var

it's value is easily (re)calculated, and we no longer have to worry
about making sure we update it everywhere.

6 years agoPerl_re_op_compile(): add S_pat_upgrade_to_utf8()
David Mitchell [Mon, 15 Apr 2013 13:20:40 +0000 (14:20 +0100)] 
Perl_re_op_compile(): add S_pat_upgrade_to_utf8()

Extract out the code that upgrades the pattern string to utf8 (and adjusts
any code-block indices) into a separate function, S_pat_upgrade_to_utf8().

As well as being tidier, we'll be calling the code from other places
shortly.

6 years agoperldelta: ExtUtils::MakeMaker update v5.17.11
Ricardo Signes [Sat, 20 Apr 2013 02:01:38 +0000 (22:01 -0400)] 
perldelta: ExtUtils::MakeMaker update

6 years agoupdate Module::CoreList for v5.17.11
Ricardo Signes [Sat, 20 Apr 2013 01:40:16 +0000 (21:40 -0400)] 
update Module::CoreList for v5.17.11

6 years agoperldelta: module updates for 5.17.11
Ricardo Signes [Sat, 20 Apr 2013 01:34:28 +0000 (21:34 -0400)] 
perldelta: module updates for 5.17.11

6 years agoacknowledgements in perldelta
Ricardo Signes [Sat, 20 Apr 2013 01:24:02 +0000 (21:24 -0400)] 
acknowledgements in perldelta

6 years agoperldiag.pod: Fix wrong Perl versions
Karl Williamson [Fri, 19 Apr 2013 23:15:30 +0000 (17:15 -0600)] 
perldiag.pod: Fix wrong Perl versions

It was planned to make certain changes in 5.18, but this didn't happen.
Change the expected version to 5.20, and add some detail.

6 years agoUpdate ExtUtils-MakeMaker to CPAN version 6.66
Chris 'BinGOs' Williams [Fri, 19 Apr 2013 19:55:57 +0000 (20:55 +0100)] 
Update ExtUtils-MakeMaker to CPAN version 6.66

  [DELTA]

  6.66 Fri Apr 19 17:53:13 BST 2013
    No changes from 6.65_03

  6.65_03 Mon Apr 15 13:44:24 BST 2013
    Test Fixes
    * Use File::Temp in parse_* tests to resolve race conditions
      on 64bit Windows
      (bingos)

  6.65_02 Sun Apr 14 10:56:41 BST 2013
    Test Fixes
    * t/xs.t is now running tests against the XS build.
      (Michael G Schwern) (Leon Timmermans)

  6.65_01 Tue Mar 19 00:06:17 CET 2013
    New Features
    * Improvements perlcritic support. (M. Schwern)
    * Improvements to dynamic linking for gcc (Tobias Leich)
      [github #43]
    * Change $(PERL_HDRS) from a hard coded list of headers to
      reading install directory for available header files. Allows
      us to work with any version of Perl properly.
      (Yves Orton, Craig A. Berry) [github #47]

    Doc Fixes
    * Numerous typo fixes. (Ben Bullock)
      [github #33] [github #34] [github #35]
    * Various FAQ and doc improvements (M. Schwern, Ivan Bessarabov)
      [github #44]

    Bug Fixes
    * fixes relating to hash ordering (Yves Orton)
      [github #46] [rt.cpan.org #83441] [rt.perl.org #116857]
    * fixes to Mksymlists (Ben Bullock, Yves Orton)
      [github #48] [github #49] [github #51]

6 years agoperldelta: significant typo!
Ricardo Signes [Fri, 19 Apr 2013 19:04:19 +0000 (15:04 -0400)] 
perldelta: significant typo!

6 years agoperldelta: update most of the delta for 5.17.11
Ricardo Signes [Fri, 19 Apr 2013 15:17:00 +0000 (11:17 -0400)] 
perldelta: update most of the delta for 5.17.11

6 years ago\N was still marked experimental in some places
David Mitchell [Fri, 19 Apr 2013 14:17:02 +0000 (15:17 +0100)] 
\N was still marked experimental in some places

6 years agoperldelta for 92fd341d6
Tony Cook [Fri, 19 Apr 2013 00:02:33 +0000 (10:02 +1000)] 
perldelta for 92fd341d6

6 years agofix dist/IO/t/cachepropagate-unix.t
Francois Perrad [Mon, 15 Apr 2013 11:37:35 +0000 (13:37 +0200)] 
fix dist/IO/t/cachepropagate-unix.t

same fix as in the last commit in cachepropagate-udp.t

Signed-off-by: Francois Perrad <francois.perrad@gadz.org>
6 years agoremove excluded test file cpan/ExtUtils-MakeMaker/t/Liblist_Kid.t
Tony Cook [Mon, 15 Apr 2013 23:29:19 +0000 (09:29 +1000)] 
remove excluded test file cpan/ExtUtils-MakeMaker/t/Liblist_Kid.t

https://rt.perl.org/rt3/Ticket/Display.html?id=117477

6 years agofix comment typo in regcomp.c
David Mitchell [Mon, 15 Apr 2013 12:40:31 +0000 (13:40 +0100)] 
fix comment typo in regcomp.c

6 years agoConverted Asian documentations to utf-8
Leon Timmermans [Sun, 14 Apr 2013 07:59:33 +0000 (09:59 +0200)] 
Converted Asian documentations to utf-8

Transcoded README.{cn,jp,ko} to utf-8
Fixed encoding lines for README.{cn,jp,ko,tw}
Fixed verbatim text for README.{cn,ko}

6 years agoDocument that range operator '..' can not be overloaded.
Moritz Lenz [Thu, 11 Apr 2013 13:17:04 +0000 (15:17 +0200)] 
Document that range operator '..' can not be overloaded.

Also document that this means that ranges and bigint.pm do not mix perfectly.
Bump version numbers.

6 years agoProvide file and subroutine-level documentation in POD format.
James E Keenan [Sat, 2 Mar 2013 18:52:27 +0000 (13:52 -0500)] 
Provide file and subroutine-level documentation in POD format.
Incorporate Nicholas Clark's suggestions.
Correct pod formatting errors.

For: RT #117003

6 years agoSubject: [PATCH] Update INSTALLDIRS to favor installation under 'site'.
James E Keenan [Sat, 13 Apr 2013 16:45:10 +0000 (17:45 +0100)] 
Subject: [PATCH] Update INSTALLDIRS to favor installation under 'site'.

For: RT #116479

6 years agoUpdate CPAN to CPAN version 2.00
Chris 'BinGOs' Williams [Sat, 13 Apr 2013 23:34:44 +0000 (00:34 +0100)] 
Update CPAN to CPAN version 2.00

  [DELTA]

  2013-04-12  Andreas Koenig  <k@UX31A>

   * release 2.00 (at Lancester #QA2013)

   * Removed the trial status for the release in the Makefile.PL

   * Merge with App::Cpan 0.61 (just a version number change)

6 years agoPorting/curliff.pl no longer needed; delete it.
James E Keenan [Fri, 22 Mar 2013 01:40:34 +0000 (21:40 -0400)] 
Porting/curliff.pl no longer needed; delete it.

Documentation patch submitted by Brad Gilbert++ provoked discussion concerning
whether this program is still needed.  Consensus was that it is not.

For: RT #117185

6 years agoB::Deparse: document that `state sub` is unimplemented
Aaron Crane [Fri, 22 Feb 2013 16:18:33 +0000 (16:18 +0000)] 
B::Deparse: document that `state sub` is unimplemented

6 years agodeparse.t: delete now-unneeded __WARN__ suppression
Aaron Crane [Fri, 12 Apr 2013 15:08:40 +0000 (16:08 +0100)] 
deparse.t: delete now-unneeded __WARN__ suppression

B::Deparse no longer emits the warnings in question.

6 years agoB::Deparse: stub implementation of deparsing lexical subs
Aaron Crane [Fri, 22 Feb 2013 16:15:46 +0000 (16:15 +0000)] 
B::Deparse: stub implementation of deparsing lexical subs

This doesn't work properly, but (a) it's better than nothing, and (b) it
suppresses some unsightly "unexpected OP_INTROCV" warnings from the test
suite, fixing RT #116821.

6 years ago[MERGE] handle /(?{})/ with overload::constant qr
David Mitchell [Fri, 12 Apr 2013 10:30:25 +0000 (11:30 +0100)] 
[MERGE] handle /(?{})/ with overload::constant qr

The reworking of the re_eval implementation for 5.17.1 made the assumption
that constant strings within literal patterns were, um, constant.

It turns out this this is an invalid assumption, because

    overload::constant qr => { sub return bless [], 'Foo' }

can cause the constant bits of a pattern, like foo, bar in

    /foo(?{...})bar/

to get replaced with (for example) blessed objects: so the 'constant' SV
attached to an OP_CONST is actually a blessed object, that could itself be
overloaded with string or concat methods say, or could be a qr// object
etc.

The commits in this merge (hopefully) fix the various problems this
assumption caused: chiefly with qr// objects containing compiled (?{})
code that were getting re-stringified and thus failing unless in the
presence of use re 'eval' (and sometimes failing even in its presence).
Also, runtime patterns could trigger a recursive call to the overload
method, and eventually stack overflow and SEGV.

See [perl #116823].

6 years agofix runtime /(?{})/ with overload::constant qr
David Mitchell [Wed, 10 Apr 2013 15:10:28 +0000 (16:10 +0100)] 
fix runtime /(?{})/ with overload::constant qr

There are two issues fixed here.

First, when a pattern has a run-time code-block included, such as

    $code = '(?{...})'
    /foo$code/

the mechanism used to parse those run-time blocks: of feeding the
resultant pattern into a call to eval_sv() with the string

    qr'foo(?{...})'

and then extracting out any resulting opcode trees from the returned
qr object -- suffered from the re-parsed qr'..' also being subject to
overload:constant qr processing, which could result in Bad Things
happening.

Since we now have the PL_parser->lex_re_reparsing flag in scope throughout
the parsing of the pattern, this is easy to detect and avoid.

The second issue is a mechanism to avoid recursion when getting false
positives in S_has_runtime_code() for code like '[(?{})]'.
For patterns like this, we would suspect that the pattern may have code
(even though it doesn't), so feed it into qr'...' and reparse, and
again it looks like runtime code, so feed it in, rinse and repeat.
The thing to stop recursion was when we saw a qr with a single OP_CONST
string, we assumed it couldn't have any run-time component, and thus no
run-time code blocks.

However, this broke qr/foo/ in the presence of overload::constant qr
overloading, which could convert foo into a string containing code blocks.

The fix for this is to change the recursion-avoidance mechanism (in a way
which also turns out to be simpler too). Basically, when we fake up a
qr'...' and eval it, we turn off any 'use re eval' in scope: its not
needed, since we know the .... will be a constant string without any
overloading. Then we use the lack of 'use re eval' in scope to
skip calling S_has_runtime_code() and just assume that the code has no
run-time patterns (if it has, then eventually the regex parser will
rightly complain about 'Eval-group not allowed at runtime').

This commit also adds some fairly comprehensive tests for this.

6 years agoadd lex_re_reparsing boolean to yy_parser struct
David Mitchell [Tue, 9 Apr 2013 16:17:16 +0000 (17:17 +0100)] 
add lex_re_reparsing boolean to yy_parser struct

When re-parsing a pattern for run-time (?{}) code blocks,
we end up with the EVAL_RE_REPARSING flag set in PL_in_eval.
Currently we clear this flag as soon as scan_str() returns, to ensure that
it's not set if we happen to parse further patterns (e.g. within the
(?{ ... }) code itself.

However, a soon-to-be-applied bugfix requires us to know the reparsing
state beyond this point. To solve this, we add a new boolean flag to the
parser struct, which is set from PL_in_eval in S_sublex_push() (with the
old value being saved). This allows us to have the flag around for the
entire pattern string parsing phase, without it affecting nested pattern
compilation.

6 years agoEliminate PL_reg_state.re_reparsing, part 2
David Mitchell [Thu, 4 Apr 2013 16:50:22 +0000 (17:50 +0100)] 
Eliminate PL_reg_state.re_reparsing, part 2

The previous commit added an alternative flag mechanism to
PL_reg_state.re_reparsing, but kept the old one around for consistency
checking. Remove the old one now.

6 years agoEliminate PL_reg_state.re_reparsing, part 1
David Mitchell [Thu, 4 Apr 2013 16:29:53 +0000 (17:29 +0100)] 
Eliminate PL_reg_state.re_reparsing, part 1

PL_reg_state.re_reparsing is a hacky flag used to allow runtime
code blocks to be included in patterns. Basically, since code blocks
are now handled by the perl parser within literal patterns, runtime
patterns are handled by taking the (assembled at runtime) pattern,
and feeding it back through the parser via the equivalent of
    eval q{qr'the_pattern'},
so that run-time (?{..})'s appear to be literal code blocks.
When this happens, the global flag PL_reg_state.re_reparsing is set,
which modifies lexing and parsing in minor ways (such as whether \\ is
stripped).

Now, I'm in the slow process of trying to eliminate global regex state
(i.e. gradually removing the fields of PL_reg_state), and also a change
which will be coming a few commits ahead requires the info which this flag
indicates to linger for longer (currently it is cleared immediately after
the call to scan_str().

For those two reasons, this commit adds a new mechanism to indicate this:
a new flag to eval_sv(), G_RE_REPARSING (which sets OPpEVAL_RE_REPARSING
in the entereval op), which sets the EVAL_RE_REPARSING bit in PL_in_eval.

Its still a yukky global flag hack, but its a *different* global flag hack
now.

For this commit, we add the new flag(s) but keep the old
PL_reg_state.re_reparsing flag and assert that the two mechanisms always
match. The next commit will remove re_reparsing.

6 years agore_op_compile(): reapply debugging statements
David Mitchell [Thu, 28 Mar 2013 15:29:14 +0000 (15:29 +0000)] 
re_op_compile(): reapply debugging statements

These were temporarily removed a few commits ago to make rebasing easier.

(And since the code's been simplified in the conflicting branch, not so
many debug statements had to be added back as were in the original).

6 years agoHandle overloading properly in compile-time regex
David Mitchell [Thu, 28 Mar 2013 14:11:16 +0000 (14:11 +0000)] 
Handle overloading properly in compile-time regex

[perl #116823]

In re_op_compile(), there were two different code paths for compile-time
patterns (/foo(?{1})bar/) and runtime (/$foo(?{1})bar/).

The code in question is where the various components of the pattern
are concatenated into a single string, for example, 'foo', '(?{1})' and
'bar' in the first pattern.

In the run-time branch, the code assumes that each component (e.g. the
value of $foo) can be absolutely anything, and full magic and overload
handling is applied as each component is retrieved and appended to the
pattern string.

The compile-time branch on the other hand, was a lot simpler because it
"knew" that each component is just a simple constant SV attached to an
OP_CONST op. This turned out to be an incorrect assumption, due to
overload::constant qr overloading; here, a simple constant part of a
compile-time pattern, such as 'foo', can be converted into whatever the
overload function returns; in particular, an object blessed into an
overloaded class. So the "simple" SVs that get attached to OP_CONST ops
can in fact be complex and need full magic, overloading etc applied to
them.

The quickest solution to this turned out to be, for the compile-time case,
extract out the SV from each OP_CONST and assemble them into a temporary
SV** array; then from then onwards, treat it the same as the run-time case
(which expects an array of SVs).

6 years agore-indent after last change
David Mitchell [Thu, 28 Mar 2013 13:08:42 +0000 (13:08 +0000)] 
re-indent after last change

(only whitespace changes)

6 years agore_op_compile(): unify 1-op and N-op branches
David Mitchell [Thu, 28 Mar 2013 12:07:18 +0000 (12:07 +0000)] 
re_op_compile(): unify 1-op and N-op branches

When assembling a compile-time pattern from a list of OP_CONSTs (and
possibly embedded code-blocks), there were separate code paths for a
single arg (a lone OP_CONST) and a list of OP_CONST / DO's.
Unify the branches into single loop.

This will make a subsequent commit easier, where we will need to do more
processing of each "constant".

Re-indenting has been left to the commit that follows this.

6 years agore_op_compile(): simplify a code snippet
David Mitchell [Mon, 25 Mar 2013 17:23:12 +0000 (17:23 +0000)] 
re_op_compile(): simplify a code snippet

and eliminate one local var.

6 years agore-indent code after previous commit
David Mitchell [Mon, 25 Mar 2013 17:19:23 +0000 (17:19 +0000)] 
re-indent code after previous commit

(whitespace changes only)

6 years agoregex and overload: unifiy 1 and N arg branches
David Mitchell [Mon, 25 Mar 2013 17:06:47 +0000 (17:06 +0000)] 
regex and overload: unifiy 1 and N arg branches

When compiling a regex, something like /a$b/ that parses two two args,
was treated in a different code path than /$a/ say, which is only one arg.

In particular the 1-arg code path, where it handled "" overloading, didn't
check for a loop (where the ""-sub returns the overloaded object itself) -
the N-arg branch did handle that. By unififying the branches, we get that
fix for free, and ensure that any future fixes don't have to be applied to
two separate branches.

Re-indented has been left to the commit that follows this.

6 years agore_op_compile(): temp remove some debugging code
David Mitchell [Thu, 28 Mar 2013 15:08:27 +0000 (15:08 +0000)] 
re_op_compile(): temp remove some debugging code

These four DEBUG_PARSE_r()'s were recently added to a block I code
which I have just been extensively reworking in a separate branch.
Temporarily remove these statements to allow my branch to be rebased;
I'll re-add them (or similar) afterwards.

6 years agopod/perlsec.pod: fix typo and tweak wording
Aaron Crane [Thu, 11 Apr 2013 15:28:39 +0000 (16:28 +0100)] 
pod/perlsec.pod: fix typo and tweak wording

6 years agoFix post-install instructions in README.vms.
Craig A. Berry [Thu, 11 Apr 2013 03:25:35 +0000 (22:25 -0500)] 
Fix post-install instructions in README.vms.

perl_setup.com gets installed, so we might as well run it from
where we have it rather than copying it somewhere.

And we really shouldn't be recommending putting things in sys$share,
even as a second choice.

6 years agoProvide proper link to original Dylan paper.
James E Keenan [Wed, 10 Apr 2013 10:54:02 +0000 (11:54 +0100)] 
Provide proper link to original Dylan paper.

Patch submitted by Dmitry Karasik++.  For: RT #117519

6 years agoDirectory rename no longer needed on VMS.
Craig A. Berry [Sat, 6 Apr 2013 15:45:04 +0000 (10:45 -0500)] 
Directory rename no longer needed on VMS.

As of 5.18.0, Perl on VMS can (at last) be built in and installed
from a directory having dots in the name, so it is no longer
necessary to rename the top-level source directory before building.

The pertinent instructions have been removed from README.vms, so
we also no longer need to update the version number that was
embedded in those instructions.

6 years agoAssorted updates to README.vms
Craig A. Berry [Sat, 6 Apr 2013 03:14:16 +0000 (22:14 -0500)] 
Assorted updates to README.vms

6 years agoperlop.pod: Fix typo that yields wrong info
Karl Williamson [Fri, 5 Apr 2013 18:37:56 +0000 (12:37 -0600)] 
perlop.pod: Fix typo that yields wrong info

6 years agoS_* functions should be STATIC
Jan Dubois [Thu, 4 Apr 2013 21:12:04 +0000 (14:12 -0700)] 
S_* functions should be STATIC

6 years agohandy.h: Remove docs for non-existent macro
Karl Williamson [Fri, 29 Mar 2013 18:29:46 +0000 (12:29 -0600)] 
handy.h: Remove docs for non-existent macro

In commit 3c3ecf18c35ad7832c6e454d304b30b2c0fef127, I mistakenly added
documentation for a non-existent macro.  It turns out that only the
variants listed for that macro exist, and not the base macro.  Since we
are in code freeze, the solution has to be not to change code by adding
the base macro, but to delete the documentation, or change it to refer
to just the existing versions.  In order to not cause an entry that is
anomalous to the others, for this release, I'm just getting rid of the
documentation.

6 years agoimprove hash related documentation in perlfunc and perlsec to reflect new hash random...
Yves Orton [Fri, 29 Mar 2013 11:27:46 +0000 (12:27 +0100)] 
improve hash related documentation in perlfunc and perlsec to reflect new hash randomization logic

6 years agoFix perlfunc.pod to reflect changes to split " " logic
Yves Orton [Fri, 29 Mar 2013 11:03:08 +0000 (12:03 +0100)] 
Fix perlfunc.pod to reflect changes to split " " logic

6 years agoRemove the non-inline function S_croak_memory_wrap from inline.h.
Andy Dougherty [Wed, 27 Mar 2013 19:54:05 +0000 (15:54 -0400)] 
Remove the non-inline function S_croak_memory_wrap from inline.h.

This appears to resolve these three related tickets:

    [perl #116989] S_croak_memory_wrap breaks gcc warning flags detection
    [perl #117319] Can't include perl.h without linking to libperl
    [perl #117331] Time::HiRes::clock_gettime not implemented on Linux (regression?)

This patch changes S_croak_memory_wrap from a static (but not inline)
function into an ordinary exported function Perl_croak_memory_wrap.
This has the advantage of allowing programs (particuarly probes, such
as in cflags.SH and Time::HiRes) to include perl.h without linking
against libperl.  Since it is not a static function defined within each
compilation unit, the optimizer can no longer remove it when it's not
needed or inline it as needed.  This likely negates some of the savings
that motivated the original commit 380f764c1ead36fe3602184804292711.
However, calling the simpler function Perl_croak_memory_wrap() still
does take less set-up than the previous version, so it may still be a
slight win.  Specific cross-platform measurements are welcome.

6 years agomakedef.pl shouldn't prepend Perl_ to symbols already starting with Perl_.
Andy Dougherty [Thu, 28 Mar 2013 00:11:34 +0000 (20:11 -0400)] 
makedef.pl shouldn't prepend Perl_ to symbols already starting with Perl_.

In the next patch, I have Perl_croak_memory_wrap defined in embed.fnc with
the 'nroX' flags, since this is a private function used by public macros.
I used the long form of the name Perl_croak_memory_wrap everywhere, and
used the 'o' flag so that embed.h wouldn't contain a useless #define
croak_memory_wrap Perl_croak_memory_wrap.  Unfortunately, makedef.pl
(used by the Win32 build process) didn't know what to do with that entry
and created an entry Perl_Perl_croak_memory_wrap.   Changing makedef.pl
to use the 'o' flag to decide whether to add the Perl_ prefix resulted
in over 50 other symbols changing in the output of makedef.pl.  I don't
know if the changes are correct or if the 'o' flag is in error on those
entries in embed.fnc, but I don't have time to check them all out.

This patch just stops makedef.pl from adding a Perl_ prefix if there is
already one there.

6 years agoExporter on CPAN is 5.68 make blead reflect this
Chris 'BinGOs' Williams [Wed, 27 Mar 2013 16:53:12 +0000 (16:53 +0000)] 
Exporter on CPAN is 5.68 make blead reflect this

6 years agoeliminate the only internal uses of HvFILL
Yves Orton [Wed, 27 Mar 2013 12:20:08 +0000 (13:20 +0100)] 
eliminate the only internal uses of HvFILL

The usages are as far as I know incorrect anyway. We resize
the hash bucket array based on the number of keys it holds,
not based on the number of buckets that are used, so this
usage was wrong anyway.

Another bug that this revealed is that the old code would allow
HvMAX(hv) to fall to 0, even though every other part of the
core expects it to have a minimum of 7 (meaning 8 buckets).

As part of this we change the hard coded 7 to a defined constant
PERL_HASH_DEFAULT_HvMAX.

After this patch there remains one use of HvFILL in core, that used
for scalar(%hash) which I plan to remove in a later patch.

6 years agoprevent SEGV from buffer read overrun, and refactor away duplicated code
Yves Orton [Wed, 27 Mar 2013 10:17:25 +0000 (11:17 +0100)] 
prevent SEGV from buffer read overrun, and refactor away duplicated code

The split patch introduced a buffer read overrun error in sv_dump() when
stringifying empty strings. This bug was always existant but was probably
never triggered because we almost always have at least one extflags set,
so it never got an empty buffer to show. Not so with the new compflags. :-(

6 years agofix comment, reindent and add parenthesis for clarity
Yves Orton [Mon, 25 Mar 2013 22:15:00 +0000 (23:15 +0100)] 
fix comment, reindent and add parenthesis for clarity

I had to stare at this expression and make sure there wasn't
anything tricky for too long, so I added parens, and reindented
it.

6 years agorework split() special case interaction with regex engine
Yves Orton [Mon, 25 Mar 2013 22:23:40 +0000 (23:23 +0100)] 
rework split() special case interaction with regex engine

This patch resolves several issues at once. The parts are
sufficiently interconnected that it is hard to break it down
into smaller commits. The tickets open for these issues are:

  RT #94490  - split and constant folding
  RT #116086 - split "\x20" doesn't work as documented

It additionally corrects some issues with cached regexes that
were exposed by the split changes (and applied to them).

It effectively reverts 5255171e6cd0accee6f76ea2980e32b3b5b8e171
and cccd1425414e6518c1fc8b7bcaccfb119320c513.

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 enables pp_regcomp() to know whether it was called
as part of split, which allows the RXf_SPLIT to be passed into run
time regex compilation. We also preserve the original flags so
pattern caching works properly, by adding a new property to the
regexp structure, "compflags", and related macros for accessing it.
We preserve the original flags passed into the compilation process,
so we can compare when we are trying to decide if we need to
recompile.

Note that this essentially the opposite fix from the one applied
originally to fix #94490 in 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. (Which is what we did.)

Also, it doesn't make sense to move the special case detection logic
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 " ".

The other major change as result of this patch is it effectively
reverts commit cccd1425414e6518c1fc8b7bcaccfb119320c513, which
was intended to get rid of RXf_SPLIT and RXf_SKIPWHITE, which
and free up bits in the regex flags structure.

But we dont want to get rid of these vars, and it turns out that
RXf_SEEN_LOOKBEHIND is used only in the same situation as 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.

6 years agosimplify regcomp.c by using vars to avoid repeated macros
Yves Orton [Mon, 25 Mar 2013 22:06:22 +0000 (23:06 +0100)] 
simplify regcomp.c by using vars to avoid repeated macros

Use two temporary variables to simplify the logic, and maybe
speed up a nanosecond or two.

Also chainsaw some long dead logic. (I #ifdef'ed it out years ago)

6 years agoImprove how regcomp.pl handles multibits
Yves Orton [Mon, 25 Mar 2013 19:08:56 +0000 (20:08 +0100)] 
Improve how regcomp.pl handles multibits

In preparation for future changes.

6 years agoSilence "smartmatch is experimental" warnings in autodie
Brian Fraser [Mon, 25 Mar 2013 04:46:43 +0000 (01:46 -0300)] 
Silence "smartmatch is experimental" warnings in autodie