-DPERL_TRACE_OPS to produce reports on executed OP counts

This produces a report on the number of OPs of a given type that were
executed at the end of a program run. This can be useful in multiple
ways. One, it can help determine hotspots for optimization (yes, I know
execution count is not equal execution time). It can also help with
determining whether a given change to perl has had the desired effect on
deterministic programs.

Remove defunct DESCRIP.MMS cleanup rules.

Rules to remove C and object files from vms/ext were made redundant when
commit 26dd53a231877708 in Sep 2009 moved the XS extensions from there to
ext/

The wildcard rule to remove t/lib/vms*.t, which has been in
vms/descrip_mms.template since the file was added by commit 97abc6adffcd3efc
in June 1998 was effectively made redundant when it was duplicated by 4
specific rules for the 4 files it matched added by commit 493ba88a837f5a6b
in June 2001.

The rule to delete t/lib/vmsish.t was made redundant when vms/ext/vmsish.*
were moved to lib/ by commit 9f84c00564fd021b in Nov 2001.

Move VMS::Filespec from vms/ext to ext/

This simplifies the VMS Makefile. It would have simplified the VMS Makefile
further if it had had the correct rules to delete [.lib.VMS]Filespec.pm
which are now no longer needed. (The generated ext/VMS-Filespec/DESCRIP.MMS
will now take care of this.)

vms/ext/filespec.t does not need to be +x

The mode of this file has rattled back and forth between +x and -x since it
was first added. It makes no difference which it is, so remove -x and hence
1 special case.

Merge in the improvements to the build helper module FindExt.

Refactor FindExt, merging scan_ext() and find_ext().

The return value of FindExt::scan_ext() has never been used, since FindExt
was first added by commit 8e2329934bcca9c5 in April 2001. The call to
FindExt::extensions() has no side effects, so it can be eliminated. Hence
FindExt::scan_ext() is a trivial wrapper around FindExt::find_ext(), and the
two can be merged.

Also, simplify the logic for "known" extensions. The complexity of checking
the hash first was needed when extension directories were nested. It should
have been removed as part of commit 1f8a0b38638b171c in Feb 2009.

Skip most of FindExt's tests for troublesome configurations.

There are various various things that break the test's assumptions.
1) If Encode is a static extension, then Configure has special case logic
   to add Encode/* as static extensions
2) -Uusedl causes Encode to be a static extension, and drops building
    XS::APItest and XS::Typemap
3) Any use of -Dnoextensions to choose not to build a extension is not known
   by the test

If any of these are true, FindExt::extensions() and $Config{extensions} will
differ, and most of the tests are going to fail. Moreover, failure doesn't
tell us anything interesting. So don't run those tests.

In FindExt.t, move the main loop's comparison logic into a subroutine.

Minor refactors to FindExt's test, removing code duplication.

Use a ternary instead of if/unless on the same $^O test.
Use a loop to call FindExt::scan_ext()
As FindExt exports nothing, we can require it rather than using it.

Thanks to FindExt::apply_config() we're now able to test dynamic extensions.

FindExt::apply_config() mimic's Configure's logic, which means that FindExt's
idea of which extensions should be built is consistent with Configure's.

Correct a type in FindExt::apply_config in the "I18N-Langinfo" code.

Commit 557ab4cb986767c7 (Feb 2011) which added this routine had
$config->{i_nl_langinfo} not $config->{d_nl_langinfo} ('i' should be 'd').

The logic for I18N::Langinfo should now be correct.

In FindExt, eliminate _ext_ne() and make extensions() a simple subroutine.

Previously _ext_ne() was a generator function, and extensions() and
known_extensions() were generated by it. Now that known_extensions() has a
different implementation, extensions() was the last user of _ext_ne(), so
there's no saving by keeping the complexity.

Also add Encode's sub-modules to known_extensions when building statically.

There is code in Configure to treat Encode specially when it is specified as
a statically linked extension. By default, Encode builds separated shared
objects for each of its subdirectories. This works well with DynaLoader,
and the top level perl Makefile doesn't even notice this, because it doesn't
have to list these libraries as things it links with at compile time.

For a static link, Encode builds a separate *.a file for each of its
subdirectories. The top level Makefile *does* need to know about these, as
a static link requires them all to be listed. Hence the work-around is to
treat Encode as a set of nested modules if linked statically.

We can't do this in Makefile.SH because the various Encode submodules are
installed as separate *.a files in the tree, and so need to continue to be
treated as distinct modules in case ExtUtils::MakeMaker is asked to (re)link
a static perl with an additional extension.

I suspect that the most elegant fix would be to tweak Encode's top level
Makefile.PL to link everything into one *.a if it is building statically.
I'm not sure how to do that, and it would need to be accepted upstream.

Add non-XS extensions to known_extensions.

Previously "known_extensions" was misnamed, as it only contained known XS
extensions. grep.cpan.me suggests that there are only 10 mentions of it
outside the core, and none of them rely on this existing behaviour.

Update the descriptions of extensions, known_extensions and nonxs_ext in
Porting/Glossary.

These changes need replicating into configure.com.

Remove Configure code that supported the old-style nested layout for ext/

5.10.1 switched to the new layout, so this code would only be useful for
backporting to maint-5.8. That isn't going happen, so it can go.

Trim the explicit Makefile rules to generate {mini,}perlmain.o

These duplicate the suffix rules used for general .c -> .o compilation.
makedepend automatically generates a dependency for miniperlmain.o on
patchlevel.h

OP*method was added in c106c2be8b83ee but never used

Branch predictor hints: exists is mostly run on hashes

S_strip_spaces doesn't need to be seen out of core

Patches must not be sent via git's format-patch/send-email

updated to match perlgit.pod

#118675 fix 4 porting/pod_rules.t uses different perl than compiled one

See rt ticket #118675 for background on this patch.

dist/lib/Makefile.PL: change INSTALLDIRS to 'site' for 5.12 and later

perldelta for c448c12411b1ba

Make perlbug look up the list of local patches at run time

Re-parsing patchlevel.h in Perl by perlbug.PL is error prone
and apparently unnecessary. The same information is available
to perlbug via Config::local_patches().

This fixes [perl #118433].

Fix to make 8d455b9f99c1046e969462419b0eb5b8bf740a47 not a lie

Previous commit 8d455b9f99c1046e969462419b0eb5b8bf740a47 was a partial
lie. This commit fixes it up not to be a lie and to avoid mortalizing
the HV.

Avoid needless refcount and mortialization on pp_anonhash

pp_anonhash can be used to construct both bare hashes and hashrefs. In
the hashref case, it used to create an HV and mortalize it. Then it went
through the parameters on the stack and copied them into the hashref.
This can throw exceptions which would make the HV leak if it hadn't been
mortalized.

After potentially copying the arguments, pp_anonhash would then in the
hashREF case increment the refcount on the HV *again*, create an RV for
the HV, and mortalize that RV before pushing it on the stack.

Instead, we can get away with constructing the HV and only mortalizing
it if there's no mortalizable ref to clean up if there's an exception.
This should remove a fair fraction of work in the common case of empty {}
hash ref construction.

Fix regex seqfault 5.18 regression

This segfault is a result of an optimization that can leave the
compilation in an inconsistent state.

  /f{0}/

doesn't match anything, and hence should be removable from the regex for
all f.  However,

  qr{(?&foo){0}(?<foo>)}

caused a segfault.  What was happening prior to this commit is that
(?&foo) refers to a named capture group further along in the regex.
The "{0}" caused the "(?&foo)" to be discarded prior to setting up the
pointers between the two related subexpressions; a segfault follows.

This commit removes the optimization, and should be suitable for a
maintenance release.

One might think that no one would be writing code like this, but this
example was distilled from machine-generated code in Regexp::Grammars.

Perhaps this optimization can be done, but the location I chose for
checking it was during parsing, which turns out to be premature.  It
would be better to do it in the optimization phase of regex compilation.
Another option would be to retain it where it was, but for it to operate
only on a limited set of nodes, such as EXACTish, which would have no
unintended consequences.  But that is for looking at in the future; the
important thing is to have a simple patch suitable for fixing this
regression in a maintenance release.

For the record, the code being reverted was mistakenly added by me in
commit 3018b823898645e44b8c37c70ac5c6302b031381, and wasn't even
mentioned in that commit message.  It should have had its own commit.

Merge the branch that purged various under-used Makefile targets.

Document the removed Makefile targets in perldelta.

In perlhacktips, suggest a shell loop to generate all .gcov files.

Eliminate the perl.gprof and perl.gcov Makefile targets.

I don't feel that it's worthwhile having specific named targets for
building named binaries for use with gprof and gcov given that one has to
(re)Configure with the appropriate C compiler flags, hence all the object
files and the F<perl> that the build tree would build are just as enabled
(or contaminated) with profiling code as the specially named binary.

Update the documentation on using gprof and gcov to reflect that the binary
named F<perl> is now the binary that is profiled.

Run Porting/podtidy on pod/perlhacktips.pod

Update perlhacktips to note that Address Sanitizer is now also in gcc 4.8

Also s/linux/Linux/ in two places.

In perlhacktips, no need to give 3 ways to set an environment variable.

Remove the explicit purify/quantify/purecov targets and documentation.

It's not clear whether IBM still sell quantify or purecov. They still seem
to sell purify, but I'm not sure if anyone is using it these days to detect
bugs in perl.

This doesn't prevent anyone from using these tools if they have them, as
it's still possible to run the commands by "hand". But by removing probably
unused code and documentation, the signal to noise ratio improves.

We don't actually need to set $ENV{PERL} for the tests to work.

Whatever the executable is named at the top level, it's always symlinked
as ./perl in t, so there's no need to set an environment variable to
override the expected name.

valgrind doesn't require that perl was built with -g, so remove the check.

C<make test.valgrind> will run quite happily on a perl built with
optimisation and without debugging symbols. So don't enforce -g.

Inline the Makefile target minitest.prep into its only user.

This is strictly a refactoring, so do not change the rules themselves, despite
them being ugly and fragile.

Remove Makefile targets and tools related to Irix and Tru64 debugging tools.

Remove the targets:

perl.pixie perl.pixie.atom perl.pixie.config perl.pixie.irix perl.third
perl.third.config

It's still possible to run the actions these targets "by hand", if desired.
This commit removes the convenience targets from the Makefile, reducing its
complexity. It also removes the related support scripts testall.atom and
thirdclean from Porting/

pixie is a performance analysis tool for Irix and Tru64
Third Degree is a memory checker tool for Tru64

Given that Tru64 went out of support at the end of 2012, and Irix goes out
of support at the end of 2013, it's very unlikely that anyone is still
actively profiling or debugging perl on either platform, and hence using
these targets. It's been several years since we've even had a regular bug
report from either platform.

Remove various rarely used test targets from the generated Makefile.

Remove these targets and their documentation:

check.third check.utf16 check.utf8 coretest minitest.utf16 test.deparse
test.taintwarn test.third test.torture test.utf16 test.utf8
test_notty.deparse test_notty.third test_prep.third torturetest ucheck
ucheck.third ucheck.utf16 ucheck.valgrind utest utest.third utest.utf16
utest.valgrind

It's still possible to run the actions these targets "by hand", if desired.
This commit simply removes the convenience targets from the Makefile,
reducing its complexity.

[perl #71680] hints to use gdbm compat for [NO]DBM_File on Win32

Small stylistic improvement; add one POD formatting character.

Give little more examples to interpolated typemap variables

Added an example for $type Perl variable interpolated by typemap.
and adjusted an example of $ntype Perl variable of typemap to
illustrate its effect.

Make t/comp/parser.t get the correct libraries.

In principle it shouldn't need libraries, but an eval of a utf8
constant now triggers automatic loading of utf8.pm, and it was
looking for that in the usual @INC locations set at configuration
time.  Which just might match an installed perl rather than the
perl being tested.  So make sure we get the correct libraries.

change tied_method to use SVs with precomputed hash values

change magic_methcall to use SV with shared hash value

Perl_magic_methcall is not public API, so there is no
need to add another function and we can just change
function's arguments.

SV_CONST(name) and PL_sv_consts

SV_CONST(XXX) returns SV* that contains "XXX" string.
SVs are built on demand and stored in interp's structure
for re-use. All SVs have precomputed hash value.

Creates SVs on demand, we don't want 35 SV created during
compile time or cloned during thread creation.

G_METHOD_NAMED flag for call_method and call_sv

Can be used when it's known that method name has no
package part - just method name.

With flag set SV with precomputed hash value is used
and pp_method_named is called instead of pp_method.
Method lookup is faster.

perldiag: Consistent spaces after dots

Update IPC-Cmd to CPAN version 0.82

  [DELTA]

  Changes for 0.82    Sat Jun 29 22:11:22 BST 2013
  =================================================
  * Typo fixes (David Steinbrunner)

op.c: Suppress compiler warning

Sorry, commit 08aff5359 was not quite ready and I pushed it too soon.

The purpose of the if block that it removed was to suppress a warn-
ing about an unused variable, but it was a very strange way of accom-
plishing that.

We have a much simpler way that takes only one line and expresses its
intent clearly.

regenerate t/porting/known_pod_issues.dat

Run the pedantic checks when regenerating the database

Make the two checks of possible poor uses of C<>
pedantic checks.

Allow --pedantic to turn on those tests in addition to
the environmnt variable.

do not worry about long verbatim lines w/o env var

To run these tests, set PERL_POD_PEDANTIC in the environment.

This needs further testing, at least, to ensure that it behaves correctly
when regenerating the known problem files.

Revert "Make t/podcheck.t less sensitive"

This reverts commit f26da014a698383ac348973050af3e754752e6ab.

Conflicts:
t/porting/known_pod_issues.dat

op.c: Remove dummy code from const_sv_xsub

This was added in commit 9cbac4c7 with no explanation.  It has been
#ifdeffed out since it was added.  That commit was supposedly just for
compiler warnings.  I think this was something else the author was
playing with that got combined in the same patch by mistake.

perlfunc: consistent spaces after dots

plus one typo fix

Clarify variable lists for my, our, state.

7b2d3c0 Added description of the Benchmark object to doc

op.c:cv_ckproto_len_flags: do null checks first

Checking local variables for nullness is faster than calling ckWARN_d,
which involves a function call.

Reinstate UTF8f

This format string allows char*s to be interpolated with the
utf8ness and length specified as well, avoiding the need to create
extra SVs:

Perl_croak(aTHX_ "Couldn't twiggle the twoggle in \"%"UTF8f"\"",
                  UTF8fARG(is_utf8, len, s));

This is the second attempt.

I screwed up in commits 1c8b67b38f0a5 and b3e714770ee1 because
I didn’t really understand how varargs functions receive their
arguments.

They are like structs, in that different members can be different
sizes.  So therefore both ends--the caller and the called--*must* get
the casts right, or the data will be corrupted.

The main mistake I made was to use %u in the format for the first
argument and then retrieve it as UV (a simple typo, I meant unsigned
int or U32--I don’t remember).

To be on the safe side, I added a UTF8fARG macro (after SVfARG), which
(unlike SVfARG) takes three arguments and casts them explicitly, mak-
ing it much harder to get this wrong at call sites.

make sure the prototype actually matches

because:

a) I think it better demonstrates the fix, the following failed without
the patch:

./perl -Ilib -le 'my $proto = "\x{30cd}"; eval "sub f($proto) {}"; print prototype(\&f); print prototype(\&f) eq $proto'

b) I can envision bugs that might preserve UTF-8 but mis-manage the content

pad.c, S_cv_clone: Maintain the utf8-ness of the cloned cv

Because of a missing SvUTF8_on() in cv_clone(), these two were different:

    use utf8;
    eval "   sub foo ($;\x{30cd});"
    eval "my sub foo ($;\x{30cd});"

Because the lexical version would lose the UTF8 flag in the
prototype.

perlexperiment: mark :pop layer as accepted

MANIFEST: add t/porting/readme.t

Fix Porting/README.pod so it passes its new test.

Added entries for sync-with-cpan and README.pod itself.  Rearranged
entries to be sorted consistently.

t/porting/readme.t: Check Porting/README.pod consistency

This is a slightly expanded (or bloated) version of the patch
Dennis Kaarsemaker <dennis@kaarsemaker.net> submitted.

Correct the SYNOPSIS for Module::CoreList::Utils

Update HTTP-Tiny to CPAN version 0.034

  [DELTA]

0.034     2013-06-26 19:02:25 America/New_York

  [ADDED]

  - Added support for 'Basic' authorization from
    user:password parameters in the URL

cv_ckproto should disregard spaces

This included some refactoring to break down the original
large if block into smaller, more manageable chunks,
although the only functional change was to pass the two
string buffers through S_strip_spaces.

t/re/reg_mesg.t: Add diagnostic output on some failures

[perl #117751] prevent POSIX::AUTOLOAD recursing if POSIX$(so) fails to load

Use -Wno-unused-value also on other clang compilers

clang++ or clang-3.2, ...

[perl #117535, #76910] Fix bogus ambiguity warnings

‘Ambiguous use of * resolved as operator *’: This message can occur in
cases where there is no multiplication operator, so what it is saying
is completely wrong.

When the lexer parses a bareword, it looks at the previous character
and warns if it happens to match /[*%&]/, so foo**bar and foo&&bar
result in this warning, as does print $%foo.

The purpose of the code is to catch *bar *bar or &black &sheep.

To avoid false positives, when emitting one of the three operators
* % & the lexer can record that fact, so when it sees a bareword pre-
ceded by one of those three characters, instead of guessing that the
infix operator was used, it will *know*.

The test cases added also trigger ‘Bareword found where operator
expected’.  I don’t know whether that should change, but at least the
current behaviour is tested, so we will know when it does change.

regen/genpacksizetables.pl: Add comment

perlguts: Nit

embed.fnc: S_ptr_hash is inline

S_ptr_hash is declared with PERL_STATIC_INLINE in hv.c, but embed
thinks it is just static, so the proto.h and hv.c definitions do not
match, resulting in warnings.

Update Digest-SHA to CPAN version 5.85

  [DELTA]

5.85  Wed Jun 26 04:05:26 MST 2013
  - workaround for repeated calls to shaclose (ref. Bug #86295)
    -- need to explicitly reset internal pointer to NULL
      ref. shaclose() in SHA.xs
  - corrected typos in shasum script
    -- ref. Bug #85430

Put all sort arguments in list context

The arguments following the first were using the context the enclosing
function was called in.

sub context { warn qw[void scalar list][wantarray + defined wantarray ] }
sub foo { sort +context, context; print "------\n"; }
foo;
$_ = foo;
[foo];
__END__

Output:

list at - line 1.
void at - line 1.
------
list at - line 1.
scalar at - line 1.
------
list at - line 1.
list at - line 1.
------

Extend the list context to all arguments.

Fix up f_sort.t for changes in the prev commit

Put sort arguments in lvalue context

Since $a and $b are aliased to the actual scalars being sorted, and
since they can be modified, the list of items needs to be in lvalue
context, like the arguments to grep.  Otherwise implementation
details leak through, in that sort{$a=1} $_,... will modify $_, but
sort{$a=1} $#_,... will fail to modify $#_.

The way I have written the loop and if() condition (the if inside the
loop) may seem odd and inefficient, but the next commit will take
advantage of that.

In-place sort should not leave array read-only

$ ./perl -Ilib -e '@a=1..2; eval { @a=sort{die} @a }; warn "ok so far\n"; @a = 1'
ok so far
Modification of a read-only value attempted at -e line 1.

If something goes wrong inside the sort block and it dies, we still
need to make sure we turn off the read-only flag on that array.

document that it is the operator that determines the operation

In many other dynamic languages it is the operator plus the type of the
first operand, so it is worth mentioning.

Increase $if::VERSION to 0.0603

Added example usage and SEE ALSO links to similar modules in doc for if.pm

op.c:S_simplify_sort: remove redundant OPf_STACKED check

S_simplify_sort is only called from one spot and only when the
OPf_STACKED flag is not set.

op.c:ck_sort: Restore HINT_LOCALIZE_HH check

I remove this by mistake in commit 354dd559d99.  It makes no
difference to the behaviour.  This check is just for efficiency.

Revert "Use UTF8f in more places"

This reverts commit acc19697c67fa63c10e07491b670a26c48f4175f.

This and the other UTF8f patch are causing significant problems on some
configurations on 32-bit platforms.  We've decided to revert them until
they can be resubmitted after the kinks get ironed out.

Revert "UTF8f"

This reverts commit 670610ebb17508101065cc5f5ecfe616aace5335.

This and the other UTF8f patch are causing significant problems on some
configurations on 32-bit platforms.  We've decided to revert them until
they can be resubmitted after the kinks get ironed out.

Add tests for a backreference following a literal, which is a different codepath

/\87/ is parsed through a different code path than /foo\87/ so we
test that they both work properly when there are sufficient capture
buffers defined. We test the fail cases in the re/re_tests corpus,
but the success cases are easier managed in re/pat.t.

Fix rules for parsing numeric escapes in regexes

Commit 726ee55d introduced better handling of things like \87 in a
regex, but as an unfortunate side effect broke latex2html.

The rules for handling backslashes in regexen are a bit arcane.

Anything starting with \0 is octal.

The sequences \1 through \9 are always backrefs.

Any other sequence is interpreted as a decimal, and if there
are that many capture buffers defined in the pattern at that point
then the sequence is a backreference. If however it is larger
than the number of buffers the sequence is treated as an octal digit.

A consequence of this is that \118 could be a backreference to
the 118th capture buffer, or it could be the string "\11" . "8". In
other words depending on the context we might even use a different
number of digits for the escape!

This also left an awkward edge case, of multi digit sequences
starting with 8 or 9 like m/\87/ which would result in us parsing
as though we had seen /87/ (iow a null byte at the start) or worse
like /\x{00}87/ which is clearly wrong.

This patches fixes the cases where the capture buffers are defined,
and causes things like the \87 or \97 to throw the same error that
/\8/ would. One might argue we should complain about an illegal
octal sequence, but this seems more consistent with an error like
/\9/ and IMO will be less surprising in an error message.

This patch includes exhaustive tests of patterns of the form
/(a)\1/, /((a))\2/ etc, so that we dont break this again if we
change the logic more.

Document and clean up -s option to xsubpp

At the same time, discourage its use. It's an obscure option that, most
of the time, does the opposite of what people actually need. If nothing
else, it should be a feature of XS instead of xsubpp.

But it exists, so documenting it with a warning is the right thing to
do.

Stop "sv_2mortal(&PL_sv_yes)" and "(void)sv_newmortal()" in ParseXS

This problem was brought up in #115796.  Both of those lines of code that
ParseXS put out when dealing with T_BOOL were unnecessary, and caused a
some inefficiencies (extra calls). Since typemaps can have complicated
evaluation and include Perl code, see commit    9712754a3e, it is best to
eval the typemap entry first, then regexp it to see what it looks like,
not regexp the unevaled entry possibly containing Perl. In case a typemap
entry is maintaining state inside ParseXS (venturing into the undocumented
and unsupported), (I've never seen it done) don't eval it twice if it can
be avoided. Someone might want to change the typemap entry to multiple
eval in the future, but don't introduce it now if it can be avoided.

Using T_BOOL by name to see an immortal is a bad idea, since any XS module
can reuse the typemap entry, so best to regexp for something that looks
like it would return an immortal, "= &PL_sv_* ;" or "= boolSV(". In the
future someone might want to introduce a macro that does nothing, except
gives a signal to ParseXS that an expression returns an immortal or an
already mortaled SV, to suppress the sv_2mortal call.

The tests in 001-basic.t might break in the future with changes to ParseXS
or the Perl API, but I assume they will be fixed at that point in time.

Note: This patch was amended by the committer to apply cleanly to a
newer version of ExtUtils::ParseXS and to include all necessary test
changes.

EU::ParseXS: Test cleanup

Lots of dead code and some inflexibilities wrt. running tests from / or
t/.

EU::ParseXS: Move several constants out of the runtime object

EU::ParseXS: Cosmetics; more explicitness in *_handler

Basically, using named lexical beats $_ by a long shot since they don't
magically propagate into functions called.

EU::ParseXS: Use OO version of ExtUtils::ParseXS in test

Sort of. Breaking encapsulation, but that's better than not even having
a blessed object at all.

EU::ParseXS: Simplify output typemap code generation (targetable)

EU::ParseXS: Cosmetics; better variable naming

EU::ParseXS: Fix targetable size detection

Adds new / vastly improved tests for 'targetable'.
Also improves targetable documentation.