| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
Removes 'the' in front of parameter names in some instances.
|
| |
|
|
| |
The generation number is no longer stored in the SvUVX() field
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
xpadl_alloc should really be pointer to a struct with a flexible array
member, but flexible array members aren't portable enough among CCs. While
debugging the padlist API for memory corruption (caused by an unrelated
XS module), I saw that the pointer in the first slice of xpadl_alloc
pointed to an AV head of gibberish but 2nd slice was fine. This was
confusing and led me to belive the memory corruption was a bad write to
the array in xpadl_alloc. PadlistARRAY's POD a couple pages down mentions
that index 0 is not an AV *, but the struct comments just said
"pointer to beginning of array of AVs " and didnt mention index 0.
Fix the comments to make it clear what xpadl_alloc is. Add a union so it
is easier to analyze a crash dump/breakpoint with a C debugger, without
writing new code "PADNAMELIST * pnl = PadlistNAMES(pl);" in many places
and recompiling the interp with -O0, just to be able to inspect the
padnamelist struct.
|
| |
|
|
|
|
|
|
|
|
|
| |
The PadlistNAMES() macro was introduced with v5.17.3-69-g86d2498.
This macro happened to be lvalue-capable, although it wasn't documented
as such.
v5.21.6-163-g9b7476d as a side effect, broke the lvalueness, which broke
Coro.
This commit restores the lvalueness.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An empty cpan/.dir-locals.el stops Emacs using the core defaults for
code imported from CPAN.
Committer's work:
To keep t/porting/cmp_version.t and t/porting/utils.t happy, $VERSION needed
to be incremented in many files, including throughout dist/PathTools.
perldelta entry for module updates.
Add two Emacs control files to MANIFEST; re-sort MANIFEST.
For: RT #124119.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 8771da69db30134352181c38401c7e50753a7ee8.
Pad lists need to carry IDs around with them, so that when something
tries to close over a pad, it is possible to confirm that the right
pad is being closed over (either the original outer pad, or a clone of
it). (See the commit message of db4cf31d1, in which commit I added an
ID to the padlist struct.)
In 8771da69 I found that I could use the memory address of the pad’s
name list (name lists are shared) and avoid the extra field.
Some time after 8771da69 I realised that a pad list could be freed,
and the same address reused for another pad list, so using a memory
address may not be so wise. I thought it highly unlikely, though, and
put it on the back burner.
I have just run into that. t/comp/form_scope.t is now failing
for me with test 13, added by db4cf31d1. It bisects to 3d6de2cd1
(PERL_PADNAME_MINIMAL), but that’s a red herring. Trivial changes
to the script make the problem go away. And it only happens on non-
debugging builds, and only on my machine. Stepping through with gdb
shows that the format-cloning is following the format prototype’s out-
side pointer and confirming that it is has the correct pad (yes, the
memory addresses are the same), which I know it doesn’t, because I can
see what the test is doing.
While generation numbers can still fall afoul of the same problem, it
is much less likely.
Anyway, the worst thing about 8771da69 is the typo in the first word
of the commit message.
|
| |
|
|
|
|
| |
See
<CACmk_tvkTETxz2eFc-bJfXEhWRjAexuvv4zw4Z036OJHpWfXVA@mail.gmail.com>
and <20141202004047.10267.qmail@lists-nntp.develooper.com>.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
If we define the struct a little differently, we can begin the string
buffer two bytes into a pointer, rather than pointer-aligned. In case
some platforms can compare pointer-aligned string faster, I added a
#define to allow that. But on 64-bit darwin the speed is identical
either way:
$ time ./miniperl -e 'eval q|my$a;|x50000 . q|eval q<my $A>|'
I ran this three times in each mode, and the average of the user times
differed by less than 1%.
|
| |
|
|
|
|
|
|
|
|
|
| |
distinct from SV. This should fix the CPAN modules that were failing
when the PadnameLVALUE flag was added, because it shared the same
bit as SVs_OBJECT and pad names were going through code paths not
designed to handle pad names.
Unfortunately, it will probably break other CPAN modules, but I think
this change is for the better, as it makes both pad names and SVs sim-
pler and makes pad names take less memory.
|
| |
|
|
|
|
| |
We refer to ‘fake’ entries in various places in the documentation,
and we still have the word FAKE in PARENT_FAKELEX_FLAGS, so noting
this should be helpful.
|
| |
|
|
|
| |
GVs have been using ‘constant’ pad names for a while now, since
v5.21.3-188-gc2bad63.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prior to 5.16, pad names never used the UTF8 flag, and all non-ASCII
pad names were in UTF8. Because the latter was consistently true,
everything just worked anyway.
In 5.16, UTF8 handling was done ‘properly’, so that non-ASCII UTF8
strings were always accompanied by the UTF8 flag.
Now, it is still the case that the only non-ASCII names to make their
way into pad name code are in UTF8. Since ASCII is a subset of UTF8,
we effectively *always* have UTF8 pad names. So the flag handling is
actually redundant.
If we just assume that all pad names are UTF8 (which is true), then
we don’t need to bother with the flag checking. There is actually
no reason why we should have two different encodings for storing
pad names.
So this commit enforces what has always been the case and removes the
extra code for converting between Latin-1 and UTF8. Nothing on CPAN
is using the UTF8 flag with pads, so nothing should break. In fact,
we never documented padadd_UTF8_NAME.
|
| |
|
|
| |
This is in preparation for making PADNAME a separate type.
|
| |
|
|
|
|
|
| |
We only use PAD_COMPNAME_TYPE in one place, so wrapping it in a func-
tion doesn’t save us anything, and probably slows things down if
anything. Furthermore, PadnameTYPE will soon become even simpler
than before.
|
| |
|
|
|
|
|
|
|
| |
This is in preparation for making PADNAME a separate type.
This commit is not perfect. What I did was temporarily make PADNAME a
separate struct identical to struct sv and make whatever changes were
necessary to avoid compiler warnings. In some cases I had to add tem-
porary SV casts.
|
| | |
|
| |
|
|
|
| |
This will be used to record whether a pad entry is used as an lvalue
multiple times. If so, it cannot be used as a constant.
|
| |
|
|
|
| |
It should be SV *, just like PAD_SVl, since (except under DEBUGGING)
it is actually the same macro.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The PAD_COMPNAME api, created in dd2155a49b , originally had alot of,
multi-eval problems, since av_fetch would be repeatedly called in macro
expansions. Later in commit b21dc0313d , an incomplete attempt at removing
multi-eval was done. Also in commit 035dab7448 added more multi-eval
problems. Prior to commit dd2155a49b , the code used a seemingly random
mix of av_fetch and AvARRAY, so both are ok. To fix this, replace av_fetch
with func-free AvARRAY. Since existing code has lval 0 to av_fetch and
unconditional deref on ret, a segv is fine to detect breakage.
A #define PAD_COMPNAME_SV(po) \
((assert(!SvMAGICAL(PL_comppad_name))),(AvARRAY(PL_comppad_name)[(po)]))
shows the AV is ! magical/tied during smoke. The assert was not added for
perf reasons on debugging builds. Inline funcs were not used for better
compiler optimizing if PAD_COMPNAME_FLAGS_isOUR is immediatly
followed by PAD_COMPNAME_OURSTASH (2 statements), as in scan_inputsymbol.
Inlines are not guaranteed to be inlined all the time on all compilers in all
situations, Visual C especially. Also inline is more likely to cause readding of
multi-eval problems than the macro if future changes to the API put the inline
func in a multi-eval macro.
On VC 2003 32bit .text section of perl521.dll dropped from 0xC296F to
0xC281F bytes of machine code with this patch.
|
| |
|
|
|
|
| |
MAD = Misc Attribute Decoration; unmaintained attempt at preserving
the Perl parse tree more faithfully so that automatic conversion to
Perl 6 would have been easier.
|
| | |
|
| | |
|
| |
|
|
| |
They have been wrong since I added them.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Under ithreads, constants and GVs are stored in the pad.
When names are looked up up in a pad, the search begins at the end and
works its way toward the beginning, so that an $x declared later masks
one declared earlier.
If there are many constants at the end of the pad, which can happen
for generated code such as lib/unicore/TestProp.pl (which has about
100,000 lines and over 500,000 pad entries for constants at the
end of the file scope’s pad), it can take a long time to search
through them all.
Before commit 325e1816, constants used &PL_sv_undef ‘names’. Since
that is the default value for array elements (when viewed directly
through AvARRAY, rather than av_fetch), the pad allocation code did
not even bother storing the ‘name’ for these. So the name pad (aka
padnamelist) was not extended, leaving just 10 entries or so in the
case of lib/unicore/TestProp.pl.
Commit 325e1816 make pad constants have &PL_sv_no names, so the
name pad would be implicitly extended as a result of storing
&PL_sv_no, causing a huge slowdown in t/re/uniprops.t (which runs
lib/unicore/TestProp.pl) under threaded builds.
Now, normally the name pad *does* get extended to match the pad,
in pad_tidy, but that is skipped for string eval (and required
file scope, of course). Hence, wrapping the contents of
lib/unicore/TestProp.pl in a sub or adding ‘my $x’ to end of it will
cause the same slowdown before 325e1816.
lib/unicore/TestProp.pl just happened to be written (ok, generated) in
such a way that it ended up with a small name pad.
This commit fixes things to make them as fast as before by recording
the index of the last named variable in the pad. Anything following
that is disregarded in pad lookup and search begins with the last
named variable. (This actually does make things faster before for
subs with many trailing constants in the pad.)
This is not a complete fix. Adding ‘my $x’ to the end of a large file
like lib/unicore/TestProp.pl will make it just as slow again.
Ultimately we need another algorithm, such as a binary search.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently &PL_sv_undef as a pad name can indicate either a free slot
available for use by pad_alloc or a slot used by an op target (or,
under ithreads, a constant or GV).
Currently pad_alloc distinguishes between free slots and unnamed slots
based on whether the value in the pad has PADMY or PADTMP set. If
neither is set, then the slot is free. If either is set, the slot
is in use.
This makes it rather difficult to distinguish between constants stored
in the pad (under ithreads) and targets. The latter need to be copied
when referenced, to give the impression that a new scalar is being
returned by an operator each time. (So \"$a" has to return a refer-
ence to a new scalar each time, but \1 should return the same one.)
Also, constants are shared between recursion levels. Currently, if
the value is marked READONLY or is a shared hash key scalar, it is
shared. But targets can also me shared hash keys, resulting in bugs.
It also makes it impossible for the same constant to be shared by mul-
tiple pad slots, as freeing one const op will turn off the PADTMP flag
while the other slot still uses it, making the latter appear to be
free. Hence a lot of copying occurs under ithreads. (Actually, that
may not be true any more since 3b1c21fabed, as freed const ops swipe
their constants from the pad. But right now, a lot of copying does
still happen.)
Also, XS modules may want to create const ops that return the same
mutable SV each time. That is currently not possible without
various workarounds including custom ops and references. (See
<https://rt.perl.org/rt3/Ticket/Display.html?id=105906#txn-1075354>.)
This commit changes pad_alloc and pad_free to use &PL_sv_no for con-
stants and updates other code to keep all tests passing. Subsequent
commits will actually use that information to fix bugs.
This will probably break PadWalker, but I think it is an acceptable
trade-off. The alternative would be to make PadnamePV forever more
complex than necessary, by giving it a special case for &PL_sv_no and
having it return NULL.
I gave PadnameLEN a special case for &PL_sv_undef, so it may appear
that I have simply shifted the complexity around. But if pad names
stop being SVs, then this exception will simply disappear, since the
global &PL_padname_undef will have 0 in its length field.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I added pad IDs so that a pad could record which pad it closes over,
to avoid problems with closures closing over the wrong pad, resulting
in crashes or bizarre copies. These pad IDs were shared between
clones of the same pad.
In commit 9ef8d56, for efficiency I made clones of the same closure
share the same pad name list.
It has just occurred to be that each padlist containing the same pad
name list also has the same pad ID, so we can just use the pad name
list itself as the ID.
This makes padlists 32 bits smaller and eliminates PL_pad_generation
from the interpreter struct.
|
| |
|
|
| |
This reverts commit d2c8bf052f5a8bb99050f6d2418d77151eb4b468.
|
| | |
|
| |
|
|
|
|
| |
I used PadnameIs* for OUR, because I was copying
PAD_COMPNAME_FLAGS_isOUR. STATE should be consistent with it. And it
was missing the double bang, making the docs wrong.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After a while, I realised that it can be confusing for PAD_ARRAY and
PAD_MAX to take a pad argument, but for PAD_SV to take a number and
PAD_SET_CUR a padlist.
I was copying the HEK_KEY convention, which was probably a bad idea.
This is what we use elsewhere:
TypeMACRO
----=====
AvMAX
CopFILE
PmopSTASH
StashHANDLER
OpslabREFCNT_dec
Furthermore, heks are not part of the API, so what convention they use
is not so important.
So these:
PADNAMELIST_*
PADLIST_*
PADNAME_*
PAD_*
are now:
Padnamelist*
Padlist*
Padname*
Pad*
|
| | |
|
| |
|
|
| |
It would help to define these macros properly.
|
| |
|
|
|
|
|
|
| |
If CPAN modules should not assume that pad names are SVs, we need
to provide a better way than newSVpvn(PADNAME_PV(pn),PADNAME_LEN(pn))
to get an SV out of it, as, knowing that pad names are just SVs, the
core can do it more efficiently by simply returning the pad name
itself.
|
| |
|
|
|
| |
I think this is the last bit of pad-as-sv stuff that was not
abstracted away in pad-specific macros.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we are making padlists their own type, and no longer AVs, it makes
sense to add APIs for pads, too, so that CPAN code that needs to
change now will only have to change once if we ever stop pads them-
selves from being AVs.
There is no reason pad names have to be SVs, so I am adding sep-
arate APIs for pad names, too. The AV containing pad names is
now officially a PADNAMELIST, which is accessed, not via
*PADLIST_ARRAY(padlist), but via PADLIST_NAMES(padlist).
Future optimisations may even merge the padlist with its name list so
I have also added macros to access the parts of the name list directly
from the padlist.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CVs close over their outer CVs. So, when you write:
my $x = 52;
sub foo {
sub bar {
sub baz {
$x
}
}
}
baz’s CvOUTSIDE pointer points to bar, bar’s CvOUTSIDE points to foo,
and foo’s to the main cv.
When the inner reference to $x is looked up, the CvOUTSIDE chain is
followed, and each sub’s pad is looked at to see if it has an $x.
(This happens at compile time.)
It can happen that bar is undefined and then redefined:
undef &bar;
eval 'sub bar { my $x = 34 }';
After this, baz will still refer to the main cv’s $x (52), but, if baz
had ‘eval '$x'’ instead of just $x, it would see the new bar’s $x.
(It’s not really a new bar, as its refaddr is the same, but it has a
new body.)
This particular case is harmless, and is obscure enough that we could
define it any way we want, and it could still be considered correct.
The real problem happens when CVs are cloned.
When a CV is cloned, its name pad already contains the offsets into
the parent pad where the values are to be found. If the outer CV
has been undefined and redefined, those pad offsets can be com-
pletely bogus.
Normally, a CV cannot be cloned except when its outer CV is running.
And the outer CV cannot have been undefined without also throwing
away the op that would have cloned the prototype.
But formats can be cloned when the outer CV is not running. So it
is possible for cloned formats to close over bogus entries in a new
parent pad.
In this example, \$x gives us an array ref. It shows ARRAY(0xbaff1ed)
instead of SCALAR(0xdeafbee):
sub foo {
my $x;
format =
@
($x,warn \$x)[0]
.
}
undef &foo;
eval 'sub foo { my @x; write }';
foo
__END__
And if the offset that the format’s pad closes over is beyond the end
of the parent’s new pad, we can even get a crash, as in this case:
eval
'sub foo {' .
'{my ($a,$b,$c,$d,$e,$f,$g,$h,$i,$j,$k,$l,$m,$n,$o,$p,$q,$r,$s,$t,$u)}'x999
. q|
my $x;
format =
@
($x,warn \$x)[0]
.
}
|;
undef &foo;
eval 'sub foo { my @x; my $x = 34; write }';
foo();
__END__
So now, instead of using CvROOT to identify clones of
CvOUTSIDE(format), we use the padlist ID instead. Padlists don’t
actually have an ID, so we give them one. Any time a sub is cloned,
the new padlist gets the same ID as the old. The format needs to
remember what its outer sub’s padlist ID was, so we put that in the
padlist struct, too.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to fix a bug, I need to add new fields to padlists. But I
cannot easily do that as long as they are AVs.
So I have created a new padlist struct.
This not only allows me to extend the padlist struct with new members
as necessary, but also saves memory, as we now have a three-pointer
struct where before we had a whole SV head (3-4 pointers) + XPVAV (5
pointers).
This will unfortunately break half of CPAN, but the pad API docs
clearly say this:
NOTE: this function is experimental and may change or be
removed without notice.
This would have broken B::Debug, but a patch sent upstream has already
been integrated into blead with commit 9d2d23d981.
|
| |
|
|
| |
otherwise they can only be used in some header files.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See also commit cae5dbbe30.
These two lines should never produce different values:
print $x, "\n";
print eval '$x', "\n";
But they were producing different values if $x happened to have the
tale flag set. Even if my in false conditional is not supported (this
was the cause of the bug report), it should still work; and it is
not the only way to get a stale lexical in an active sub (just the
easiest way).
As long as the sub containing the eval is active, the eval should be
able to see the same variables, stale or not.
However, this does get a bit tricky in cases like this, which legiti-
mately warn (from t/lib/warnings/pad):
{
my $x = 1;
$y = \$x; # force abandonment rather than clear-in-place at scope exit
sub f2 { eval '$x' }
}
f2();
In this case the f2 sub does not explicitly close over the $x, so by
the time the eval is reached the ‘right’ $x is gone.
It is only in those cases where the sub containing the eval has
the stale variable in its own pad that we can safely ignore the
stale flag.
|
| |
|
|
|
| |
This updates the editor hints in our files for Emacs and vim to request
that tabs be inserted as spaces.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fork emulation on Windows, which clones a new thread via
perl_clone_using, expects to be able to access the current pad imme-
diately after the cloning, and crashes if there is no current pad.
PL_comppad was not being cloned explicitly, but simply looked up in
the pointer table, it being assumed that it had already been cloned.
For string evals, before commit 676a678, PL_compcv happened to point
to the eval’s CV. PL_compcv is cloned just before PL_comppad is set,
so that worked.
As of commit 676a678, PL_compcv does not point to the eval’s CV
at the eval’s run time, so the pad has not been cloned yet when
PL_comppad is set.
In the case of string evals, the CV does get cloned, but later on,
after PL_comppad is set, when the stacks are cloned.
Changing the setting of PL_comppad to do an actual cloning works, as,
when the eval’s CV is cloned later (during stack cloning), it will
simply pick up the pad that has already been cloned and is waiting for
it in the pointer table.
This stops eval 'fork' from crashing on Windows.
|
| |
|
|
|
|
|
| |
Sync copyright dates with actual changes according to git history.
[Plus run regen_perly.h to update the SHA-256 checksums, and
regen/regcharclass.pl to update regcharclass.h]
|
| |
|
|
| |
It has been unused in core since d5b1589c and is not used on CPAN.
|
| | |
|
| |
|
|
|
|
|
| |
Move several pad functions into the core API. Document the pad
functions more consistently for perlapi. Fix the interface issues
around delimitation of lexical variable names, providing _pvn, _pvs,
_pv, and _sv forms of pad_add_name and pad_findmy.
|
| |
|
|
|
| |
In Perl_find_rundefsv() and PAD_COMPNAME_FLAGS_isOUR(), replace longhand flags
test with SvPAD_OUR().
|
| |
|
|
|
|
|
|
| |
and increase its scope to all the perl core rather than just pad.c.
The scope needs to increase because we'll need to use it in op.c shortly,
and the rename is because it's about to lose any significance as a
numerical value, and just become a magic number to be tested for equality.
|
| |
|
|
| |
it reference counted. Properly solves [perl #66094]
|
