perl.git
6 years agoversion bumps and perldelta for debugger depth
Ricardo Signes [Fri, 7 Jun 2013 15:51:45 +0000 (11:51 -0400)] 
version bumps and perldelta for debugger depth

6 years agoadjust $DB::deep from 100 to 1000
Mark Jason Dominus [Fri, 7 Jun 2013 15:42:07 +0000 (11:42 -0400)] 
adjust $DB::deep from 100 to 1000

$DB::deep defaults to 100; this means that when the debugger gets 100
levels deep in subroutine calls, it automatically breaks execution.
While this might have been appropriate in 1989, in modern Perl programs,
the debugger might break before the program is even compiled.

This patch adjusts the default value up to 1000.

I was not able to find the default value documented anywhere.

6 years agoStop delete local $ENV{foo} from leaking
Father Chrysostomos [Fri, 7 Jun 2013 15:26:03 +0000 (08:26 -0700)] 
Stop delete local $ENV{foo} from leaking

It was only leaking when the env var did not already exist.

The code in question in pp.c:S_do_delete_local was calling hv_delete
to delete the element, which autovivifies, deletes, and returns a mag-
ical mortal for magical hashes.  It was assuming that if a value was
returned the element must have existed, so it was calling SvREFCNT_inc
on the returned mortal to de-mortalize it (since it has to be
restored).  Whether the element had existed previously was already
recorded in a bool named ‘preeminent’ (strange name).  This variable
should be checked before the SvREFCNT_inc.

I found the same bug in the array code path, potentially affecting
@- and @+, so I fixed it.  But I didn’t write a test, as that would
involve a custom regexp engine.

6 years agohv.c: Clarify uvar comment
Father Chrysostomos [Fri, 7 Jun 2013 03:42:30 +0000 (20:42 -0700)] 
hv.c: Clarify uvar comment

It was not clear that it referred to uvar magic.

6 years agoDon’t leak when compiling /(?[\d\d])/
Father Chrysostomos [Thu, 6 Jun 2013 21:14:06 +0000 (14:14 -0700)] 
Don’t leak when compiling /(?[\d\d])/

The ‘Operand with no preceding operator’ error was leaking the last
two operands.

6 years agoFree operand when encountering unmatched ')' in (?[])
Father Chrysostomos [Thu, 6 Jun 2013 21:07:21 +0000 (14:07 -0700)] 
Free operand when encountering unmatched ')' in (?[])

I only need to free the operand (current), not the left-paren token
that turns out not to be a paren (lparen).

For lparen to leak, there would have to be two operands in a row on
the charclass parsing stack, which currently never happens.

6 years agoStop /(?[\p{...}])/ compilation from leaking
Father Chrysostomos [Thu, 6 Jun 2013 20:42:32 +0000 (13:42 -0700)] 
Stop /(?[\p{...}])/ compilation from leaking

The swash returned by utf8_heavy.pl was not being freed in the code
path to handle returning character classes to the (?[...]) parser
(when ret_invlist is true).

6 years agoAdd a note to Win32's BUILD_STATIC configuration to include Win32CORE
Steve Hay [Thu, 6 Jun 2013 22:48:56 +0000 (23:48 +0100)] 
Add a note to Win32's BUILD_STATIC configuration to include Win32CORE

Win32CORE needs to be included for the on-demand loading of Win32 to work.
(Many of Win32's Perl level functions are pre-defined (even without a "use
Win32" statement), while the implementation is in a dynamically linked
module.)

6 years agoExclude Compress/Raw/Bzip2 from ALL_STATIC extensions for MinGW for now
Steve Hay [Thu, 6 Jun 2013 22:43:33 +0000 (23:43 +0100)] 
Exclude Compress/Raw/Bzip2 from ALL_STATIC extensions for MinGW for now

The ALL_STATIC=define build succeeds with VC++, but with MinGW it gives an
error about _BZ2_compressBlock (referenced from bzlib.o) being undefined.
I do not know why, so just exclude this extension from the list for now,
and add a note about it.

6 years agoSimplify recipes for making perl-static.exe on Win32
Steve Hay [Thu, 6 Jun 2013 22:35:55 +0000 (23:35 +0100)] 
Simplify recipes for making perl-static.exe on Win32

There is no need to link the static extension libraries as well as the
static perl library because the entire contents of all the static extension
libraries have been put into the static perl library anyway.

Also put the list of objects and libraries which perl.exe and
perl-static.exe link against in the same order as each other, and in both
makefiles, and (in makefile.mk) for both compilers, so that the
similarities and differences are more readily seen.

6 years agoFix creation of libperl519s.a on Win32 with MinGW
Steve Hay [Thu, 6 Jun 2013 22:28:07 +0000 (23:28 +0100)] 
Fix creation of libperl519s.a on Win32 with MinGW

The "ar rc" command created an invalid static perl library by putting the
static extension libraries themselves into the library rather than putting
the objects from each static extension library into it as intended (like
the VC++ "link -lib" command does).

We now extract each static extension library's objects into a temporary
directory and put the objects from there into the static perl library.

6 years agoRemove /PDB:NONE linker option from Win32 makefiles
Steve Hay [Thu, 6 Jun 2013 22:14:09 +0000 (23:14 +0100)] 
Remove /PDB:NONE linker option from Win32 makefiles

The /PDB linker option syntax changed from /PDB:{filename|NONE} to just
/PDB:filename from VC7 onwards. We do not use /PDB:NONE for most targets
anyway, so just remove it from the one place it is present to avoid
accidentally creating a file called "NONE" with all but VC6.

6 years agoEnsure Win32 [nd]make builds the 'static' target when ALL_STATIC=define
Steve Hay [Thu, 6 Jun 2013 22:05:05 +0000 (23:05 +0100)] 
Ensure Win32 [nd]make builds the 'static' target when ALL_STATIC=define

6 years agoStop (?[]) operators from leaking
Father Chrysostomos [Thu, 6 Jun 2013 15:47:31 +0000 (08:47 -0700)] 
Stop (?[]) operators from leaking

When a (?[]) extended charclass is compiled, the various operands are
stored as inversion lists in separate SVs and then combined together
into new inversion lists.  The functions that take care of combining
inversion lists only ever free one operand, and sometimes free none.
Most of the operators in (?[]) were trusting the invlist functions to
free everything that was no longer needed, causing (?[]) compilation
to leak invlists.

6 years agoperldiag: Document ‘Expecting '(?flags:(?[...'’
Father Chrysostomos [Thu, 6 Jun 2013 15:17:44 +0000 (08:17 -0700)] 
perldiag: Document ‘Expecting '(?flags:(?[...'’

6 years agoperldiag: Clarify why ‘False [] range’ can be F
Father Chrysostomos [Thu, 6 Jun 2013 13:22:45 +0000 (06:22 -0700)] 
perldiag: Clarify why ‘False [] range’ can be F

6 years agoMerge remote-tracking branch 'remotes/origin/smoke-me/env-instead-of-echo' into blead
H.Merijn Brand [Thu, 6 Jun 2013 14:18:44 +0000 (16:18 +0200)] 
Merge remote-tracking branch 'remotes/origin/smoke-me/env-instead-of-echo' into blead

6 years agoperldiag: Correct severity/category for ‘False [] range’
Father Chrysostomos [Thu, 6 Jun 2013 06:56:52 +0000 (23:56 -0700)] 
perldiag: Correct severity/category for ‘False [] range’

This can now be a fatal error or a warning.  diag.t is still not
smart enough to verify this, so it is still in its exception list.

6 years agodiag.t: Don’t confuse the two exception listse
Father Chrysostomos [Thu, 6 Jun 2013 06:44:05 +0000 (23:44 -0700)] 
diag.t: Don’t confuse the two exception listse

The second exception list is for things listed in perldiag whose cate-
gories are in need of correction or are too baffling for diag.t to
check correctly (it’s not very smart).

Due to my careless implementation in commit 62f5f54d, the second list
was also treated effectively as an addendum to the first.  Things not
listed in perldiag could be listed in the second exception list and
make tests pass.

6 years agodiag.t: Remove commented obsoleted by 62f5f54dc2d
Father Chrysostomos [Thu, 6 Jun 2013 06:33:35 +0000 (23:33 -0700)] 
diag.t: Remove commented obsoleted by 62f5f54dc2d

6 years agoAlphabetize perltrap
Father Chrysostomos [Thu, 6 Jun 2013 05:05:20 +0000 (22:05 -0700)] 
Alphabetize perltrap

Before 9b12f83b0b6, the programming languages other than Perl were in
alphabetical order.

6 years agoIn regcomp.c, Set_Node_Cur_Length() uses parse_start, so explicitly pass it.
Nicholas Clark [Wed, 5 Jun 2013 10:15:57 +0000 (12:15 +0200)] 
In regcomp.c, Set_Node_Cur_Length() uses parse_start, so explicitly pass it.

The macro Set_Node_Cur_Length() had been referring to the variable
parse_start within its body. This somewhat secret reference is potentially
risky, as it was always taking a parameter node, hence one might assume that
that was all that it used, and change the value stored in parse_start.
(Specifically, one place that assigns RExC_parse - 1 to parse_start, and later
uses parse_start + 1, which looks like an obvious cleanup candidate)

So make parse_start an explicit parameter.

Also, eliminate the never-used macro Set_Cur_Node_Length. This was added as
part of commit fac927409d5ddf11 (April 2001) but never used.

6 years agoIn S_regatom, declare parse_start when RE_TRACK_PATTERN_OFFSETS is defined.
Nicholas Clark [Tue, 4 Jun 2013 15:37:10 +0000 (17:37 +0200)] 
In S_regatom, declare parse_start when RE_TRACK_PATTERN_OFFSETS is defined.

Commit 779fedd7c3021f01 (March 2013) moved code which unconditionally used
parse_start into another block. Hence the variable is now only needed when
RE_TRACK_PATTERN_OFFSETS is defined, so wrap its declaration in #ifdef/#endif
to avoid C compiler warnings.

6 years agoDon’t leak the /(?[])/ parsing stack on error
Father Chrysostomos [Thu, 6 Jun 2013 04:40:24 +0000 (21:40 -0700)] 
Don’t leak the /(?[])/ parsing stack on error

Instead of creating the parsing stack and then freeing it after pars-
ing the (?[...]) construct (leaking it whenever one of the various
errors scattered throughout the parsing code occurs), mortalise it to
begin with and let the mortals stack take care of it.

6 years agoperldelta for #114576 (XS lvalue subs)
Father Chrysostomos [Wed, 5 Jun 2013 20:00:34 +0000 (13:00 -0700)] 
perldelta for #114576 (XS lvalue subs)

6 years agoperldelta: typo
Father Chrysostomos [Wed, 5 Jun 2013 19:57:59 +0000 (12:57 -0700)] 
perldelta: typo

6 years agoUpdate CPAN-Meta to CPAN version 2.131560
Chris 'BinGOs' Williams [Wed, 5 Jun 2013 23:39:00 +0000 (00:39 +0100)] 
Update CPAN-Meta to CPAN version 2.131560

  [DELTA]

2.131560  2013-06-05 15:26:36 America/New_York

  [DOCUMENTATION]

  - Replaced CPAN::Meta SYNOPSIS with code that actually works

6 years agouse 'env' instead of 'echo' for %ENV tests in magic.t
H.Merijn Brand [Wed, 5 Jun 2013 14:13:34 +0000 (16:13 +0200)] 
use 'env' instead of 'echo' for %ENV tests in magic.t

To prevent using weird echo commands (it can be a binary in the $PATH)
or shell quoting (Windows has env too?), use the env command.

The env command showed perfect content on old HP-UX 11.00 where the echo
command usage got it seriously wrong.

6 years agorequire.t: handle parallel runs
David Mitchell [Wed, 5 Jun 2013 10:54:36 +0000 (11:54 +0100)] 
require.t: handle parallel runs

There are random smoke failures in this test script, which are consistent
with multiple processes running the same test script in parallel, and
writing/unlinking the same (hard-coded) temp files.

As a temp hack, add a sleep(20) if this looks like its happening,
and see if the smoke issues go away.

6 years agomake some tests TODO under -DPERL_NO_COW
David Mitchell [Wed, 5 Jun 2013 10:24:20 +0000 (11:24 +0100)] 
make some tests TODO under -DPERL_NO_COW

Since it's Copy-on-Write that fixed those tests, we expect them to fail
without COW.

6 years agoRemove the unused env parameter from a2p's main, and the associated pragma.
Nicholas Clark [Tue, 4 Jun 2013 12:19:31 +0000 (14:19 +0200)] 
Remove the unused env parameter from a2p's main, and the associated pragma.

a2p's main has had the traditional Unix third parameter (env) forever.
Commit 24801a4b9a14a562 in May 2005 increased the strictness of the Tru64
compiler, and added pramgas where necessary to counter its warnings.
However, a2p's main doesn't actually *use* the env parameter, so a better
solution is to remove it. Which means that the pragma can be removed too.

6 years agodtrace.t: Don’t rely on installed strict.pm
Father Chrysostomos [Wed, 5 Jun 2013 06:38:48 +0000 (23:38 -0700)] 
dtrace.t: Don’t rely on installed strict.pm

It was failing to load strict.pm if perl had not been installed yet.

6 years ago[perl #118297] Fix interpolating downgraded variables into upgraded regexp
Dagfinn Ilmari Mannsåker [Tue, 4 Jun 2013 17:15:24 +0000 (18:15 +0100)] 
[perl #118297] Fix interpolating downgraded variables into upgraded regexp

The code alredy upgraded the pattern if interpolating an upgraded
string into it, but not vice versa.  Just use sv_catsv_nomg() instead
of sv_catpvn_nomg(), so that it can upgrade as necessary.

6 years ago-l $handle warning: globs, iorefs, utf8
Father Chrysostomos [Wed, 5 Jun 2013 01:32:46 +0000 (18:32 -0700)] 
-l $handle warning: globs, iorefs, utf8

The warning restored in commit cd22fad3cbcea only applied to globrefs,
not to globs or iorefs.  The warning message was also not utf8-clean.
This commit fixes both.

This resolves ticket #117595.

6 years agoInterix seems to have multi-arch so ask gcc where stuff is
Chris 'BinGOs' Williams [Fri, 10 May 2013 20:16:32 +0000 (21:16 +0100)] 
Interix seems to have multi-arch so ask gcc where stuff is

6 years agoremove obsolete STRUCT_MGVTBL_DEFINITION from mg.h
Daniel Dragan [Fri, 29 Mar 2013 21:54:40 +0000 (17:54 -0400)] 
remove obsolete STRUCT_MGVTBL_DEFINITION from mg.h

STRUCT_MGVTBL_DEFINITION was added in commit 0f4eea8fa1 in 5.004_67 as
part of ML thread "[PATCH 5.004_67] Fixes for broken MS compiler" and
stopped being used in commit acfe0abced in 5.7.2. STRUCT_MGVTBL_DEFINITION
was used to provide binary compatibility between C++ objs and C structs,
where extra  C++ data was stored with each function * raising the member
size to 16 bytes instead of 4 on a 32 bit build, also see
http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/2793a64f-ec09-495c-b995-4f5b98a26321

The define in struct mgvtbl is a left over that wasn't removed. Remove it
to improve code readability.

6 years agoperlipc: remove some confusing text.
Shlomi Fish [Sat, 1 Jun 2013 11:40:30 +0000 (14:40 +0300)] 
perlipc: remove some confusing text.

See: https://rt.perl.org/rt3/Ticket/Display.html?id=114444#txn-1220111

6 years ago[perl #115112] avoid repeated calls to path_is_absolute() and rename it
Tony Cook [Sun, 2 Jun 2013 01:33:44 +0000 (11:33 +1000)] 
[perl #115112] avoid repeated calls to path_is_absolute() and rename it

A micro-optimization inspired by bulk88's perl #115112.

The original proposal suggested applying a two changes that removed the
duplicate calls, and then explicitly inlined path_is_absolute().

This version removes the duplicate calls, renames the function to better
match it's purpose and asks the compiler to inline it.

6 years agoTypo fix in perlfunc [RT#118093]
Eric Brine [Wed, 22 May 2013 03:15:58 +0000 (20:15 -0700)] 
Typo fix in perlfunc [RT#118093]

This addresses an earlier fix which incorrectly changed "syntax fancy" to "fancy fancy" instead of "fancy syntax".

6 years agoStop making assumptions about uids and gids.
Brian Fraser [Thu, 23 May 2013 03:44:15 +0000 (00:44 -0300)] 
Stop making assumptions about uids and gids.

The code dealt rather inconsistently with uids and gids. Some
places assumed that they could be safely stored in UVs, others
in IVs, others in ints; All of them should've been using the
macros from config.h instead. Similarly, code that created
SVs or pushed values into the stack was also making incorrect
assumptions -- As a point of reference, only pp_stat did the
right thing:

 #if Uid_t_size > IVSIZE
mPUSHn(PL_statcache.st_uid);
 #else
 #   if Uid_t_sign <= 0
mPUSHi(PL_statcache.st_uid);
 #   else
mPUSHu(PL_statcache.st_uid);
 #   endif
 #endif

The other places were potential bugs, and some were even causing
warnings in some unusual OSs, like haiku or qnx.

This commit ammends the situation by introducing four new macros,
SvUID(), sv_setuid(), SvGID(), and sv_setgid(), and using them
where needed.

6 years ago[perl #117531] Deparse elements of %# correctly
Father Chrysostomos [Tue, 4 Jun 2013 04:57:33 +0000 (21:57 -0700)] 
[perl #117531] Deparse elements of %# correctly

They can only be referred to as $# {foo} and ${#}{foo}, not as $#{foo},
as that means $#foo.

6 years agoTraps for the unwary JS programmer (perltrap.pod)
Father Chrysostomos [Tue, 4 Jun 2013 03:48:00 +0000 (20:48 -0700)] 
Traps for the unwary JS programmer (perltrap.pod)

This is part of ticket #117507 or #109408, whichever you like.

This incorporates suggestions and corrections from Ronald Kimball and
Tom Christiansen.  Thank them!

6 years agodeparse.t: Fix test count
Father Chrysostomos [Tue, 4 Jun 2013 03:29:54 +0000 (20:29 -0700)] 
deparse.t: Fix test count

6 years agoadd a special case for VOS handling of argv[0] in magic.t
Paul Green [Wed, 27 Mar 2013 16:17:53 +0000 (12:17 -0400)] 
add a special case for VOS handling of argv[0] in magic.t

6 years agoremove an obsolete special case for VOS handling of permissions in AnyDBM_File.t
Paul Green [Wed, 27 Mar 2013 16:17:08 +0000 (12:17 -0400)] 
remove an obsolete special case for VOS handling of permissions in AnyDBM_File.t

6 years agoadd a special case for VOS handling of file position after open in tell.t
Paul Green [Wed, 27 Mar 2013 16:15:40 +0000 (12:15 -0400)] 
add a special case for VOS handling of file position after open in tell.t

6 years agoremove an obsolete VOS special case and add a new one in fs.t
Paul Green [Wed, 27 Mar 2013 16:13:47 +0000 (12:13 -0400)] 
remove an obsolete VOS special case and add a new one in fs.t

6 years agochange svpeek.t to append the VOS executable suffix to $^X
Paul Green [Wed, 27 Mar 2013 16:12:10 +0000 (12:12 -0400)] 
change svpeek.t to append the VOS executable suffix to $^X

6 years agochange DynaLoader.t to know VOS has no libc library
Paul Green [Wed, 27 Mar 2013 16:07:57 +0000 (12:07 -0400)] 
change DynaLoader.t to know VOS has no libc library

6 years agoremove obsolete VOS special cases from eu_command.t
Paul Green [Wed, 27 Mar 2013 16:05:01 +0000 (12:05 -0400)] 
remove obsolete VOS special cases from eu_command.t

6 years agoAdd Heiko Eissfeldt to AUTHORS
Father Chrysostomos [Tue, 4 Jun 2013 01:33:55 +0000 (18:33 -0700)] 
Add Heiko Eissfeldt to AUTHORS

6 years ago[perl #117311] B::Deparse with option -l leaves formfeed characters in its output
hexcoder [Tue, 4 Jun 2013 01:33:12 +0000 (18:33 -0700)] 
[perl #117311] B::Deparse with option -l leaves formfeed characters in its output

6 years agoop.h: Corrent comment about entersub strictures
Father Chrysostomos [Sun, 2 Jun 2013 23:33:31 +0000 (16:33 -0700)] 
op.h: Corrent comment about entersub strictures

Flag 2 on entersub is HINT_STRICT_REFS, not _SUBS.

6 years agoFix internal inconsistencies in style in utf8.pm docs
Eric Brine [Mon, 3 Jun 2013 17:26:11 +0000 (10:26 -0700)] 
Fix internal inconsistencies in style in utf8.pm docs

6 years agoFAIL_OK looks too much like a constant [RT##118279]
Eric Brine [Mon, 3 Jun 2013 17:21:42 +0000 (10:21 -0700)] 
FAIL_OK looks too much like a constant [RT##118279]

6 years agoPATCH: Bump Locale-Codes from 3.25 to 3.26
Sullivan Beck [Mon, 3 Jun 2013 15:05:09 +0000 (11:05 -0400)] 
PATCH: Bump Locale-Codes from 3.25 to 3.26

I just released Locale-Codes-3.26 which contains the core modules
Locale::Country, Locale::Language, and Locale::Currency.  The patch is
attached to this message.

====
Background:

The core modules Locale::Country, Locale::Language, and Locale::Currency
(all part of the Locale-Codes distribution) should be updated on a
regular basis. They contain "codes" from various internet standards
which change over time.

I plan on releasing new versions at 4 times a year to keep the codes
up-to-date. At this point, I'm not planning on any significant code
changes (other than bug fixes), so the only significant changes
between releases should be to update the codes.

>From a6cfe877326aa21c73be694f3a9d7dbe1f17961b Mon Sep 17 00:00:00 2001
From: Sullivan Beck <sbeck@cpan.org>
Date: Mon, 3 Jun 2013 10:55:38 -0400
Subject: [PATCH] Bump Locale-Codes from 3.25 to 3.26

Signed-off-by: Chris 'BinGOs' Williams <chris@bingosnet.co.uk>
6 years agoAdjust documentation for removal of splice warning
Eric Brine [Mon, 3 Jun 2013 04:46:07 +0000 (21:46 -0700)] 
Adjust documentation for removal of splice warning

6 years agoavoid undeflow in regex poscache count
David Mitchell [Mon, 3 Jun 2013 10:45:05 +0000 (11:45 +0100)] 
avoid undeflow in regex poscache count

reginfo->poscache_iter is used to count down to zero; at zero, the
superlinear cache is enabled; and for values below zero the cache is
tested. After I32_MAX iterations the count might wrap to a positive value
on 32-bit systems. So don't do that.

6 years agoperldelta for 285a3ca13
Tony Cook [Mon, 3 Jun 2013 12:57:28 +0000 (22:57 +1000)] 
perldelta for 285a3ca13

6 years ago[perl #118175] avoid making pointers outside of objects
Tony Cook [Mon, 3 Jun 2013 12:28:37 +0000 (22:28 +1000)] 
[perl #118175] avoid making pointers outside of objects

In a couple of cases, when strings were allocated above the 2GB line
on 32-bit CPUs, this could cause regexps to act strangely - not matching
or crashing perl.

The final patch in the set prevents pointer creation which the C standard
describes as undefined behaviour, but is typically safe (as long as the
pointer isn't derefed)

6 years ago[perl #118175] avoid making a pointer outside a string
Tony Cook [Sat, 1 Jun 2013 02:33:05 +0000 (12:33 +1000)] 
[perl #118175] avoid making a pointer outside a string

Simply adding scan + max causes undefined behaviour per ANSI C if the
result points outside of the object scan points at.

6 years ago[perl #118175] prevent a similar overflow for CANY
Tony Cook [Sat, 1 Jun 2013 01:10:39 +0000 (11:10 +1000)] 
[perl #118175] prevent a similar overflow for CANY

6 years ago[perl #118175] prevent a similar overflow for POSIXA
Tony Cook [Sat, 1 Jun 2013 00:54:36 +0000 (10:54 +1000)] 
[perl #118175] prevent a similar overflow for POSIXA

6 years ago[perl #118175] avoid overflowing a pointer for repeated EXACT nodes
Tony Cook [Tue, 28 May 2013 10:43:28 +0000 (20:43 +1000)] 
[perl #118175] avoid overflowing a pointer for repeated EXACT nodes

6 years agoeliminate an unused variable
Tony Cook [Mon, 3 Jun 2013 11:57:29 +0000 (21:57 +1000)] 
eliminate an unused variable

6 years agoperldelta: changed intuit API
David Mitchell [Mon, 3 Jun 2013 10:38:49 +0000 (11:38 +0100)] 
perldelta: changed intuit API

6 years ago[MERGE] get rid of (most) regex engine global state
David Mitchell [Sun, 2 Jun 2013 19:59:58 +0000 (20:59 +0100)] 
[MERGE] get rid of (most) regex engine global state

Historically, perl's regex engine was based on Henry Spencer's regex code,
which was all contained within a single file and used a bunch of static
variables to maintain the state of the current regex compile or execution.

This was perfectly adequate when only a single thread could execute a
regex, and where the regex engine couldn't be called re-entrantly.

In 5.0, these vars were promoted to be full global vars as perl became
embeddable; then in 5.5 they became part of the perl interpreter struct
when MULTIPLICITY was introduced.

In 5.6, the Perl_save_re_context() function was introduced that did a
whole bunch of SAVEPPTR(PL_bostr) type stuff, and was called in various
places where it was possible that the engine may be re-entered, to avoid
overwriting the global state of the currently executing regex. This was
particularly important now that Unicode had been introduced, and certain
character classes could trigger a call to the perl-level SWASH code, which
could itself execute a regex; and where /(?{ ... })/ code blocks could be
called which could do likewise.

In 5.10, The various PL_foo variables became fields within the new
re_save_state struct, and a new interpreter var, PL_reg_state, was
introduced which was of type struct re_save_state. Thus, all the
individual vars were still global state, but it became easier to save them
en-mass in Perl_save_re_context() by just copying the re_save_state stuct
onto the save stack and marking it with the new SAVEt_RE_STATE type.
Perl_save_re_context() was also expanded to be responsible for saving all
the current $1 values.

Up until now, that is roughly how things have remained, except for bug
fixes such as discovering more places where Perl_save_re_context() needs
to be called.

Note that, philosophically speaking at least, this is broken in two ways.
First, there's no good reason for the internal current state of the
executing regex engine to be stored in a bunch of global vars; and
secondly we're relying on potential callers of the regex engine (like the
magic tie code for example), to be responsible for being aware that they
*might* trigger re-entrancy in the regex engine, and to thus do
Perl_save_re_context() as a precaution. This is error-prone and hard to
prove correct.  (As an example, Perl_save_re_context() is only called in
the tie code if the tie code in question is doing a tied PRINT on STDERR;
clearly an unusual use case that someone spotted was buggy at some point).

The obvious fix, and the one performed by the series of commits in this
merge, is to make all the global state local to the regex engine instead.
Indeed, there is already a struct, regmatch_info, that is allocated as a
local var in regexec(), then passed as an argument to the various
lower-level functions called from regexec(). However, it only had limited
use previously, so here we expand the number of functions where it is
passed as an argument. In particular, it is now also created by
re_intuit_start(), the other main run-time entry point to the regex
engine.

However, there is a problem with this, in that various regex vars need
cleaning up on croak (e.g. they point to a malloced buffer). Since the
regmatch_info struct is just a local var on the C stack, it will be lost
by the longjmp done by a croak() before leave_scope() can clear up.

To handle this, some fields that logically should go in regmatch_info,
are instead added to two new structs: regmatch_info_aux and
regmatch_info_aux_eval; the first represents all the normal fields that
need some sort of cleanup handling; the second represents extra fields
(also possibly needing cleanup) that are only only needed if the pattern
contains /(?{})/ code blocks. These two structs are allocated in the next
two free PL_regmatch_state stack slots - since these slots are allocated
in 4K slabs anyway, they are essentially free of charge. A single
destructor function, S_cleanup_regmatch_info_aux() is then used with
SAVEDESTRUCTOR_X() to perform all cleanup at the end of execution.

In addition, all state and cleanup setup has been consolidated into a
single point near the start of regexec(); previously it was spread across
regexec(), regtry() and regmatch(). This used also to result in various
inefficencies, such as PL_regmatch_state stack freeing all higher unused
slabs at the end of each call to regmatch(), which might be called
multiple times by regexec(). Now it just frees once.

As part of this series of fixes it was necessary to change the API of
Perl_re_intuit_start(). This is because the API was broken: unlike
Perl_regexec_flags(), it didn't have a strbeg arg, and would try to guess
it from the SV (if any) passed to it. This could fail on overloaded SVs
for example, or where its called without an SV (not done from core, but
officially supported by the API). Note that this is likely to break
Re::Engine plugins, plus any code which directly calls intuit.

Finally, note that although struct re_save_state and SAVEt_RE_STATE are
gone, Perl_save_re_context() still does something useful: the equivalent
of local($1,$2...). Fixing that properly is a whole separate kettle of
fish, not addressed here.

As far as I'm aware, the only remaining global vars associated with the
regex engine are

    PL_reg_curpm, PL_regmatch_state, PL_regmatch_slab, PL_colors, PL_colorset

None of these are effected by re-entrancy. The state stack is, erm, a stack,
so it can handle re-entrancy quite happily, and the others are safe too.

6 years agodocument fields of regmatch_info struct
David Mitchell [Fri, 31 May 2013 22:44:44 +0000 (23:44 +0100)] 
document fields of regmatch_info struct

6 years agotidy up init code in regexec() and intuit_start()
David Mitchell [Fri, 31 May 2013 22:33:45 +0000 (23:33 +0100)] 
tidy up init code in regexec() and intuit_start()

Slightly reorganise the set-up code in these two functions,
for example by gathering all 'reginfo->foo =' assignments into a single
block. This is just swapping the order of a few lines, and shouldn't make
any functional difference.

6 years agobetter comment the remaining PL_ regex vars
David Mitchell [Fri, 31 May 2013 22:06:39 +0000 (23:06 +0100)] 
better comment the remaining PL_ regex vars

6 years agoeliminate PL_regdummy
David Mitchell [Fri, 31 May 2013 21:57:21 +0000 (22:57 +0100)] 
eliminate PL_regdummy

This global (per-interpreter) var is just used during regex compilation as
a placeholder to point RExC_emit at during the first (non-emitting) pass,
to indicate to not to emit anything. There's no need for it to be a global
var: just add it as an extra field in the RExC_state_t struct instead.

6 years agoeliminate PL_reg_state
David Mitchell [Fri, 31 May 2013 21:35:40 +0000 (22:35 +0100)] 
eliminate PL_reg_state

This is a struct that holds all the global state of the current regex
match.
The previous set of commits have gradually removed all the fields of this
struct (by making things local rather than global state). Since the struct
is now empty, the PL_reg_state var can be removed, along with the
SAVEt_RE_STATE save type which was used to save and restore those fields
on recursive re-entry to the regex engine.

6 years agoEliminate PL_reg_starttry
David Mitchell [Fri, 31 May 2013 21:24:54 +0000 (22:24 +0100)] 
Eliminate PL_reg_starttry

Its only used for printing debugging messages, and its value is already
available as the startpos local var in S_regmatch().

Whoo hoo! This var was the last field within the PL_reg_state global state
struct.

6 years agomake PL_reg_curpm global
David Mitchell [Fri, 31 May 2013 20:39:01 +0000 (21:39 +0100)] 
make PL_reg_curpm global

Currently PL_reg_curpm is actually #deffed to a field within PL_reg_state;
promote it into a fully autonomous perl-interpreter variable.

PL_reg_curpm points to a fake PMOP that's used to temporarily point
PL_curpm to, that we can hang the current regex off, so that this works:

    "a" =~ /^(.)(?{ print $1 })/ # prints 'a'

It turns out that it doesn't need to be saved and restored when we
recursively enter the regex engine; that is already handled by saving and
restoring which regex is currently attached to PL_reg_curpm.
So we just need a single global (per interpreter) placeholder.

Since we're shortly going to get rid of PL_reg_state, we need to move it
out of that struct.

6 years agobetter document the regex super-linear pos cache
David Mitchell [Fri, 31 May 2013 15:16:46 +0000 (16:16 +0100)] 
better document the regex super-linear pos cache

6 years agoeliminate PL_reg_poscache, PL_reg_poscache_size
David Mitchell [Fri, 31 May 2013 14:40:48 +0000 (15:40 +0100)] 
eliminate PL_reg_poscache, PL_reg_poscache_size

Eliminate these two global vars (well, fields in the global
PL_reg_state), that hold the regex super-liner cache.

PL_reg_poscache_size gets replaced with a field in the local regmatch_info
struct, while PL_reg_poscache (which needs freeing at end of pattern
execution or on croak()), goes in the regmatch_info_aux struct.

Note that this includes a slight change in behaviour.
Each regex execution now has its own private poscache pointer, initially
null.  If the super-linear behaviour is detected, the cache is malloced,
used for the duration of the pattern match, then freed.

The former behaviour allocated a global poscache on first use, which was
retained between regex executions. Since the poscache could between 0.25
and 2x the size of the string being matched, that could potentially be a
big buffer lying around unused. So we save memory at the expense of a new
malloc/free for every regex that triggers super-linear behaviour.

The old behaviour saved the old pointer on reentrancy, then restored the
old one (and possibly freed the new buffer) at exit. Except it didn't for
(?{}), so /(?{ m{something-that-triggers-super-linear-cache} })/ would
leak each time the inner regex was called. This is now fixed
automatically.

6 years agouse new cleanup for PL_regmatch_state
David Mitchell [Thu, 30 May 2013 22:44:53 +0000 (23:44 +0100)] 
use new cleanup for PL_regmatch_state

The previous commit reorganised state save and cleanup at the end of regex
execution. Use this new mechanism, by recording the original values
of PL_regmatch_slab and PL_regmatch_state in the regmatch_info_aux struct,
and restoring them and freeing higher slabs as part of the general
S_cleanup_regmatch_info_aux() destructor, rather than pushing the old
values directly onto the savestack and using another specific destructor.

Also, make the initial allocating of (up to) 3 PL_regmatch_state slots
more efficient by doing it in a loop.

We also skip the first slot; this may already be in use if we're called
reentrantly.

try 1

6 years agounify regmatch_info data
David Mitchell [Thu, 30 May 2013 15:27:09 +0000 (16:27 +0100)] 
unify regmatch_info data

Previously the regmatch_info struct was allocated as a local var on the C
stack, while some extra state (only needed for regexes having (?{})) was
malloced (as a regmatch_eval_state struct) as needed - and a destructor set
up to clean it up afterwards. This being because the stuff being cleaned
up couldn't be allocated on the C stack as it needed to hang around after
a croak().

Reorganise this so that:

* regmatch_info is on the C stack as before.

* a new struct, regmatch_info_aux is allocated within the first slot of the
  regmatch_state stack, for fields which must always exist but which need
  cleanup afterwards. This is currently unused, but will be shortly.

* a new struct, regmatch_info_aux_eval (which is just a renamed
  regmatch_eval_state struct), is optionally allocated in the second
  slot of regmatch_state. This is logically part of regmatch_info_aux,
  except that splitting it in two stops it being too large to fit in a
  regmatch_state slot (we can fit it in two instead).

(The second and third structs aren't allocated when we're intuit()
rather than regexec()).

Doing it like this simplifies allocation and cleanup: there's no need for
a malloc(), and we are already going to allocate a slab's worth of
regmatch_state slots, so using an extra one of two of them is effectively
free; and the cleanup just requires calling a single overall destructor.

In the next few commits, more of the regexec() state setup and tear-down
will be integrated into this new regime. And in particular, the new
regmatch_info_aux struct will give us somewhere to hang things like
PL_reg_poscache once it stops being global (it being local state that
needs cleanup).

6 years agomove eval_state init from regtry() to regexec()
David Mitchell [Thu, 30 May 2013 10:46:02 +0000 (11:46 +0100)] 
move eval_state init from regtry() to regexec()

regexec() calls regtry() for each match start position until a match is
found. regtry() has some code that says: "if this regex contains (?{})'s,
and if we haven't done so already, set up the extra state needed".

Move the setup one level higher, into regexec(). Here, we just do it once,
and don't have to keep checking whether we've already done it.

This is part of an effort to consolidate all regex state initialisation
into one place.

6 years agomove savestack restore from regmatch to regexec
David Mitchell [Thu, 30 May 2013 10:27:45 +0000 (11:27 +0100)] 
move savestack restore from regmatch to regexec

Currently, S_regmatch() has, in its outermost scope:

    oldsave = PL_savestack_ix;
    SAVEDESTRUCTOR_X(S_clear_backtrack_stack, NULL);
    SAVEVPTR(PL_regmatch_slab);
    SAVEVPTR(PL_regmatch_state);

    ... rest of function ....

    /* clean up; in particular, free all slabs above current one */
    LEAVE_SCOPE(oldsave);

This means that at the end of regmatch(), all slabs in the regmatch_state
stack above where we started, are freed.

Hoist this two levels higher into Perl_regexec_flags().  Now, since
a) the main activity of regexec() is call regmatch() (via regtry()) for
each possible string start position until a match is found;
b) there isn't any other savestack manipulation between the two functions;
the main affect of this change is that higher slabs in the regmatch_state
stack are only freed at the end of all match attempts from all positions,
rather than after each fail at a particular start point. Since the
repeated calls to regmatch() are likely to have a similar pattern of
regmatch_state stack usage, this should usually be an efficiency win.

It is also part of plan to consolidate all the setting up of local match
state in one place.

6 years agoeliminate PL_reg_maxiter, PL_reg_leftiter
David Mitchell [Tue, 21 May 2013 13:49:30 +0000 (14:49 +0100)] 
eliminate PL_reg_maxiter, PL_reg_leftiter

Move these two fields of PL_reg_state into the regmatch_info struct, so
they are local to each match.

6 years agoRationalise RX_MATCH_UTF8_set()
David Mitchell [Mon, 20 May 2013 16:04:44 +0000 (17:04 +0100)] 
Rationalise RX_MATCH_UTF8_set()

Now that the RXf_MATCH_UTF8 flag on a regex is just used to indicate
whether the captures on a successful match are utf8, only set
this flag at the end of a successful match, rather than at the start of
the match.

This should make no functional difference the way things stand at the
moment, but makes things conceptually cleaner.

6 years agoS_setup_eval_state: save subcoffset, not suboffset
David Mitchell [Mon, 20 May 2013 15:46:59 +0000 (16:46 +0100)] 
S_setup_eval_state: save subcoffset, not suboffset

A typo in this function meant that the same value rex->suboffset was
saved to both eval_state->suboffset and eval_state->subcoffset.

However, I can't think of a test case where this will fail, since each
qr// gets its own set of suboffset vars these days. (and thus I wonder
whether there's even any need to save them when calling (?{}).

6 years agoEliminate PL_reg_match_utf8
David Mitchell [Mon, 20 May 2013 15:22:20 +0000 (16:22 +0100)] 
Eliminate PL_reg_match_utf8

Earlier commits made the use of this var just local to the current
match, so move it to the local regmatch_info struct instead.

6 years agoregex engine: simplify is_utf8_pat handling
David Mitchell [Mon, 20 May 2013 14:04:11 +0000 (15:04 +0100)] 
regex engine: simplify is_utf8_pat handling

Since this value is actually just always equal to cBOOL(RX_UTF8(rx)),
there's no need to save the old value of the local boolean
(as u.eval.saved_utf8_pat) when switching back and forwards between
regexes with (??{}); instead, just re-calculate it whenever we switch,
and update reginfo->is_utf8_pat and its cached value in the is_utf8_pat
local var accordingly.

Also, pass reginfo as an arg to S_setup_EXACTISH_ST_c1_c2() rather than
is_utf8_pat directly; this will allow us to eliminate PL_reg_match_utf8
shortly.

A new test is included that detects a mistake I made while working up
this change: I recalculated is_utf8_pat, but forgot to update
reginfo->is_utf8_pat too.

6 years agostop callers of rex engine using RX_MATCH_UTF8_set
David Mitchell [Mon, 20 May 2013 13:17:33 +0000 (14:17 +0100)] 
stop callers of rex engine using RX_MATCH_UTF8_set

The way that the regex engine knows that the match string is utf8 is
currently a complete mess. It's partially signalled by the utf8 flag of
the passed SV, but also by the RXf_MATCH_UTF8 flag in the regex itself,
and the value of PL_reg_match_utf8.

Currently all the callers of the engine (such as pp_match, pp_split etc)
initially use RX_MATCH_UTF8_set() before calling the engine. This sets both
the RXf_MATCH_UTF8 flag on the regex, and PL_reg_match_utf8.

Then the two entry points to the engine (regexec_flags() and
re_intuit_start()) initially repeat the RX_MATCH_UTF8_set()
themselves.

Remove the usage of RX_MATCH_UTF8_set() by the callers of the engine,
and instead just rely on the engine to do it.

Also, remove the "secret" setting of PL_reg_match_utf8 by
RX_MATCH_UTF8_set(), and do it explicitly.

This is a prelude to eliminating PL_reg_match_utf8.

6 years agoadd regmatch_eval_state struct
David Mitchell [Sun, 19 May 2013 08:38:23 +0000 (09:38 +0100)] 
add regmatch_eval_state struct

Replace several PL_reg* vars with a new struct. This is part of the
goal of removing all global regex state.

These particular vars are used in the case of a regex with (?{}) code
blocks. In this case, when the code in a block is called, various bits of
state (such as $1, pos($_)) are temporarily set up, even though the match
has not yet completed.

This involves updating the current PL_curpm to point to a fake PMOP which
points to the regex currently being executed. That regex has all its
current fields that are associated with captures (such as subbeg)
temporarily saved and overwritten with the current partial match results.
Similarly, $_ is temporarily aliased to the current match string, and any
old pos() position is saved. This saving was formerly done to the various
PL_reg* vars.

When the regex has finished executing (or if the code block croaks),
its fields are restored to the original values. Since this can happen in a
croak, it may be done using SAVEDESTRUCTOR_X() on the save stack. This
precludes just moving the PL_reg* vars into the regmatch_info struct,
since that is just allocated as a local var in regexec_flags(), and would
have already been abandoned and possibly overwritten after the croak and
longjmp, but before the SAVEDESTRUCTOR_X() action is taken.

So instead we put all the vars into new struct, and malloc that on entry to
the regex engine when we know we need to copy the various fields.
We save a pointer to that in the regmatch_info struct, as well as passing
it to SAVEDESTRUCTOR_X(). The destructor may get called up to twice in the
non-croak case: first it's called explicitly at the end of regexec_flags(),
which restores subbeg etc; then again from the savestack, which just
free()s the struct. In the croak case, it's called just once, and does
both the restoring and the freeing.

The vars / PL_reg_state fields this commit eliminates are:

    re_state_eval_setup_done
    PL_reg_oldsaved
    PL_reg_oldsavedlen
    PL_reg_oldsavedoffset
    PL_reg_oldsavedcoffset
    PL_reg_magic
    PL_reg_oldpos
    PL_nrs
    PL_reg_oldcurpm

6 years agoS_setup_eval_state(): always set up destructor
David Mitchell [Sat, 18 May 2013 16:44:40 +0000 (17:44 +0100)] 
S_setup_eval_state(): always set up destructor

This function only set up a destructor if reginfo->sv existed. If not,
some stuff which was set up wouldn't be restored if the code died within a
(?{}) block.

As it happens, the way the regex engine is called from perl core means we
always pass a valid SV; but in theory someone could call the engine from
XS while passing just a string and no SV.

6 years agoS_regtry(): move eval setup code into separate fn
David Mitchell [Sat, 18 May 2013 16:25:44 +0000 (17:25 +0100)] 
S_regtry(): move eval setup code into separate fn

There's a block of code in S_regtry() that looks a bit like:

    if ((prog->extflags & RXf_EVAL_SEEN) && not_yet_done)
    {
...
    }

Move this block of code out into a separate static function,
S_setup_eval_state(). No functional changes.

Also, rename the corresponding static cleanup/destructor function from
restore_pos() to S_restore_eval_state(), to better reflect what it does
these days (restoring pos() being only a small part of it).

6 years agoremove unused reginfo->bol field
David Mitchell [Sat, 18 May 2013 14:44:03 +0000 (15:44 +0100)] 
remove unused reginfo->bol field

6 years agoeliminate PL_bostr
David Mitchell [Sat, 18 May 2013 14:40:47 +0000 (15:40 +0100)] 
eliminate PL_bostr

by moving it from the global PL_reg_state struct to the local reginfo
struct.

6 years agoadd strbeg argument to Perl_re_intuit_start()
David Mitchell [Sat, 18 May 2013 14:05:57 +0000 (15:05 +0100)] 
add strbeg argument to Perl_re_intuit_start()

(note that this is a change both to the perl API and the regex engine
plugin API).

Currently, Perl_re_intuit_start() is passed an SV, plus pointers to:
where in the string to start matching (strpos); and to the end of the
string (strend).

Unlike Perl_regexec_flags(), it doesn't also have a strbeg arg.
Because of this this, it guesses strbeg: based on the passed SV (if its
svPOK()); or just set to strpos otherwise. This latter can happen if for
example the SV is overloaded. Note also that this latter guess is wrong,
and could in theory make /\b.../ fail.

But just to confuse matters, although Perl_re_intuit_start() itself uses
its guesstimate strbeg var, some of the functions it calls use the global
value of PL_bostr instead. To make this work, the *callers* of
Perl_re_intuit_start() currently set PL_bostr first. This is why \b
doesn't actually break.

The fix to this unholy mess is to simply add a strbeg arg to
Perl_re_intuit_start(). It's also the first step to eliminating PL_bostr
altogether.

6 years agofind_byclass, regrepeat: remove is_utf8_pat arg
David Mitchell [Sat, 18 May 2013 12:25:36 +0000 (13:25 +0100)] 
find_byclass, regrepeat: remove is_utf8_pat arg

Remove the is_utf8_pat arg from these two static functions in regexec.c.
Since both these functions are now passed a valid reginfo pointer, this
info is already available as one of the fields in that struct.

6 years agoeliminiate PL_regeol
David Mitchell [Fri, 17 May 2013 16:38:26 +0000 (17:38 +0100)] 
eliminiate PL_regeol

This is another global regex state variable (actually a field of
PL_reg_state). Eliminate it by moving it into the regmatch_info struct
instead, which is local to each match. Also, rename it to strend, which is
a less misleading description in these exciting days of multi-line matches.

6 years agomake more use of regmatch_info struct.
David Mitchell [Fri, 17 May 2013 16:38:00 +0000 (17:38 +0100)] 
make more use of regmatch_info struct.

regmatch_info is a small struct that is currently directly allocated as a
local var in Perl_regexec_flags(), and has a few fields that maintain part
of the state of the current pattern match. It is passed as an arg to
various functions that regexec_flags() calls, such as regtry().

In some ways its a rival to PL_reg_state, which also maintains state for
the current match, but which is a global variable (whose state needs
saving and restoring whenever the regex engine goes reentrant). It makes
more sense to store state in the regmatch_info struct, and as a first step
in moving more state to there, this commit makes more use of
regmatch_info.

In particular, it makes Perl_re_intuit_start() also allocate such a
struct, so that now *both* the main execution entry points to the regex
engine make use of it. It's also now passed as an arg to more of the static
functions that these two op-level ones call.

Two changes of special note. First, whether S_find_byclass() got called
with a null reginfo pointer of not indicated whether it had been called
from Perl_regexec_flags() (with a valid reginfo pointer), or from
Perl_re_intuit_start() (null pointer). Since they both pass non-null
reginfo pointers now, instead we add an extra field, reginfo->intuit that
indicates who's the top-level caller.

Secondly, to allow in future for various macros to uniformly refer to
values like reginfo->foo, where the structure is actually allocated as a
local var in Perl_regexec_flags(), we change the reginfo from being the
struct itself to being a pointer to the struct, (so Perl_regexec_flags
itself now uses reginfo->foo too rather than reginfo.foo).

In summary, all the above is essentially window dressing that makes no
functional changes to the code, but will facilitate future changes.

6 years agoFix crashes after syntax errors in lexical subs
Father Chrysostomos [Sun, 2 Jun 2013 20:25:24 +0000 (13:25 -0700)] 
Fix crashes after syntax errors in lexical subs

Peter Martini fixed this in commit 89e006ae4e39db for our subs.
(Thank you, BTW, if you are reading this.)

The warning is expected; the assertion failure is not:

$ ./miniperl -Ilib -Mfeature=:all -e 'state sub a { is ref } a()'
The lexical_subs feature is experimental at -e line 1.
Assertion failed: (hek), function Perl_ck_subr, file op.c, line 10558.
Abort trap: 6
$ ./miniperl -Ilib -Mfeature=:all -e 'my sub a { is ref } a()'
The lexical_subs feature is experimental at -e line 1.
Assertion failed: (SvTYPE(_svmagic) >= SVt_PVMG), function S_mg_findext_flags, file mg.c, line 398.
Abort trap: 6
$

The prototype CV for a my sub is stored in magic attached to the pad
name.  The.  The code to fetch the prototype CV for a my sub calls
mg_find on the pad name.  If a syntax error occurs when the sub is be
ing compiled, the magic will never be attached, so the pad name (pad
names are currently SVs) will not have been upgraded to SVt_PVMG,
causing an assertion failure in mg_find, which only accepts SVs
thus upgraded.

When a pad entry is created, it is automatically filled with an empty
SV of the appropriate type.  For a subroutine, this is a nameless CV
stub.  CVs can be named in two ways, via GVs for package subs, or via
heks for lexical subs.  This stub has neither and is truly nameless.
Since a lexical sub is never installed if it contains a syntax error,
this stub is visible during subsequent compilation in the same scope.
ck_subr wasn’t prepared to handle a stub with absolutely no name
attached to it, since it is designed for handling sub calls where the
sub is known at compile time, so there must be a GV available to it,
unless the sub is lexical, and all lexical subs have heks.

This commit fixes the assumptions in both places.  Exactly what hap-
pens and what is returned is not so important, as this only hap-
pens after a syntax error, when the op tree is going to be thrown
away anyway.

6 years ago[perl #116735] Honour lexical prototypes when no parens are used
Father Chrysostomos [Sun, 2 Jun 2013 07:54:09 +0000 (00:54 -0700)] 
[perl #116735] Honour lexical prototypes when no parens are used

As Peter Martini noted in ticket #116735, lexical subs produce dif-
ferent op trees for ‘foo 1’ and ‘foo(1)’.  foo(1) produces an rv2cv
op with a padcv kid.  The unparenthetical version produces just
a padcv op.

And the difference in op trees caused lexical sub calls to honour
prototypes only in the presence of parentheses, because rv2cv_op_cv
(which searches for the cv in order to check its prototype) was
expecting rv2cv+padcv.

Not realising there was a discrepancy between the two forms, and
noticing that foo() produces *two* newCVREF ops, in commit 279d09bf893
I made newCVREF return just a padcv op for lexical subs.  At the time
I couldn’t figure out why there were two rv2cv ops, and punted on
researching it.

This is how it works for package subs:

When a sub call is compiled, if there are parentheses, an implicit '&'
is fed to the parser.  The token that follows is a WORD token with a
constant op attached to it, containing the name of the subroutine.
When the parser sees '&', it calls newCVREF on the const op to create
an rv2cv op.

For sub calls without parentheses, the token passed to the parser is
already an rv2cv op.

The resulting op tree is the same either way.

For lexical subs, I had the lexer emitting an rv2cv op in both paths,
which was why we got the double rv2cv when newCVREF was returning an
rv2cv for lexical subs.

The real solution is to call newCVREF in the lexer only when there
are no parentheses, since in that case the lexer is not going to call
newCVREF itself.  That avoids a redundant newCVREF call.  Hence, we
can have newCVREF always return an rv2cv op.

The result is that ‘foo(1)’ and ‘foo 1’ produce identical op trees for
a lexical sub.

One more thing needed to change:  The lexer was not looking at the
lexical prototype CV but simply the stub to be autovivified, so it
couldn’t see the parameter prototype attached to the CV (the stub
doesn’t have one).

The lexer needs to see the parameter prototype too, in order to deter-
mine precedence.

The logic for digging through pads to find the CV has been extracted
out of rv2cv_op_cv into a separate (non-API!) routine.

6 years agoName lexical constants
Father Chrysostomos [Sun, 2 Jun 2013 01:39:33 +0000 (18:39 -0700)] 
Name lexical constants

$ ./perl -Ilib -Mfeature=:all -e 'my sub a(){44} a()'
The lexical_subs feature is experimental at -e line 1.
Assertion failed: (hek), function Perl_ck_subr, file op.c, line 10558.
Abort trap: 6

The experimental warning is expected.  The assertion failure is not.

When a call checker is invoked, the name of the subroutine is passed
to it.  op.c:ck_subr gets the name from the CV’s cv (CvGV) or, in the
case of lexical subs, from its name hek (CvNAME_HEK).  If neither
exists, ck_subr cannot cope.

Lexical subs never have a GV pointer.  Lexical constants were acci-
dentally having neither a GV pointer nor a hek.  They should have a
hek, like other lexical subs.

6 years agolexsub.t: To-do tests for citing lex subs after errors
Father Chrysostomos [Sat, 1 Jun 2013 13:28:12 +0000 (06:28 -0700)] 
lexsub.t: To-do tests for citing lex subs after errors

This currently causes assertion failures on debugging builds.  On
non-debugging builds (untested), it probably crashes:

my sub a { foo ref } # foo must not exist
a();

6 years agoUpdate Pod-Usage to CPAN version 1.63
Chris 'BinGOs' Williams [Sun, 2 Jun 2013 08:22:51 +0000 (09:22 +0100)] 
Update Pod-Usage to CPAN version 1.63

  [DELTA]

1.63 (marekr)
- CPAN#85477: Module version not updated in last release
  ...fixed
- CPAN#85478: typo fixes
  ...corrected