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.

1 files changed, 3 insertions, 0 deletions

diff --git a/dist/ExtUtils-ParseXS/Changes b/dist/ExtUtils-ParseXS/Changes
index feb507a41e..54071a38ca 100644
--- a/dist/ExtUtils-ParseXS/Changes
+++ b/dist/ExtUtils-ParseXS/Changes
@@ -1,5 +1,8 @@
 Revision history for Perl extension ExtUtils::ParseXS.
 
+  - stop "sv_2mortal(&PL_sv_yes)" and "(void)sv_newmortal()" for immortal
+    typemap entries [perl #116152]
+
 3.18_03 - Fri Apr 19 18:40:00 CET 2013
   - Heuristic (and flawed) type canonicalization for templated
     C++ types.