This fixes two separate but related bugs.
* Thread clone crashed if any class existed with no fields in it. This
is fixed by permitting a NULL PADNAMELIST parameter to
padnamelist_dup(). [GH23771]
* Thread cloning would unreliably segfault due to missing
PadnameFIELDINFO() of an outer closure capture, depending on the
exact order of CV discovery. This is fixed by correct usage of the
PL_ptr_table to store details of cloned `struct padname_fieldinfo`
structures, and careful ordering of assignments and recursive clone
calls.
SAVEDESTRUCTOR_X needs a function whose type is 'void (pTHX_ void *)'
exactly, so introduce a little shim.
Should fix this ASan error:
scope.c:1543:13: runtime error: call to function Perl_suspend_compcv through pointer to incorrect function type 'void (*)(struct interpreter *, void *)'
An ARGS_ASSERT macro is always generated for every function listed in
embed.fnc, unless possibly suppressed with the G flag for that entry.
The generated macro is empty if there is nothing to assert.
It is mandatory (enforced through a porting test) to call that macro
when non-empty. (Hopefully the call occurs in the function the macro is
designed for, but the porting test is currently simplistic and doesn't
check for that; often compilation would fail anyway if it did get placed
in the wrong function, as the parameter names the macro expects and the
ones in the function could easily not match).
It is optional (but a good idea) to call the macro even when empty.
That way this commit would not have been necessary. From time to time,
an empty macro becomes non-empty as we figure out more things to check
for. When that happens, the porting test fails for the newly-non-empty
macros that aren't called. If the function had originally called the
empty-one, its source wouldn't have to change at all.
Several commits from now will make some ARGS_ASSERT macros non-empty;
this commit adds calls to the ones that weren't already called.
Create specific macros for incrementing the refcount of an AV, CV, GV or
HV, returning a typed pointer to avoid the caller needing to cast the
result. This yields neater easier-to-read code.
While not implemented here, this gives an opportunity to add an
`assert()` check on the SvTYPE of the structure being adjusted, for
extra debug checking during debugging builds.
Having one group containing the descriptions of all closely related
functions makes the pod more compact and makes maintenance easier; fixes
only need to be applied in one place. And it encourages the
documentation authors to compare and contrast the variants, paying
closer attention to the subtle differences between them.
And it is easier for the reader to choose the variant that is best for
their current purpose, rather than hopping around the file, unsure if
the current text is identical to that found elsewhere, or if there is a
subtle nuance (or three).
EVAL CVs are treated a bit weirdly: their CvROOT() and CvSTART() fields
don't get populated; instead the current values are stored in the
PL_eval_root and PL_eval_start variables while they are being executed.
This caused a bug in closures and nested evals when an inner eval was
repeated twice. The first inner eval accessed an outer lexical, which
caused a fake cache entry to be added to the outer eval's pad. The
second inner eval finds this cached entry, but incorrectly concludes
that the outer eval is in fact an anon sub prototype and issues a
'variable is not available' warning. This is due to this simplistic
definition in pad.c:
#define CvCOMPILED(cv) CvROOT(cv)
This commit adds a new flag, CvEVAL_COMPILED(), to indicate a
fully-compiled EVAL CV. This allows us to work around the limitation.
In an ideal world this would have been fixed instead by making EVAL CVs
first-class citizens with CvROOT() etc, but plenty of stuff seems to
assume otherwise. So I took the path of least resistance.
See https://www.perlmonks.org/?node_id=11158351
Perl was doing this:
$ perl -e'sub { CORE::state sub FOO () { 42 } }'
Attempt to free unreferenced scalar: ...
$
This warning was in particular now showing up on stderr on bleed builds:
ever since the recent addition of similar code to Deparse.t with
v5.39.9-33-g4a55343c55.
When a sub is made constant, it is converted into an XS sub, and the
IV(42) SV is stored in the CV's CvXSUBANY(cv).any_sv field.
But state subs (even const ones) get cloned if wrapped within an outer
anon sub and then that outer sub gets cloned. And it turns out that when
a const state sub is cloned, the ref count of that const SV wasn't being
incremented.
The fix is trivial. But there were two possible ways to fix it. The
approach I chose was to fix the cloning code so that it increments on
CvCONST(cv) being true in addition to on CvREFCOUNTED_ANYSV(cv) being
true.
The other approach (and arguably more logically correct) would be to set
the CVf_REFCOUNTED_ANYSV flag on const subs too, but this involves
modifying the code in multiple places, e.g. newMYSUB(), newATTRSUB_x(),
newCONSTSUB_flags(), and makes it more likely that CPAN XS code out
there which cargo-cults similar code would also need fixing. So my fix
is simpler, more robust, but less satisfying.
Note that before 5.36.0, the failing code example above would segfault
rather than warn.
This partly reverts commit 31273fbcec76b8eef204e7d7c8dde2b78d0e0ce5
which was committed in https://github.com/Perl/perl5/pull/21915
It has been found that this warning creates too many warnings from
otherwise-harmless situations, and additionally acts inconsistently with
other behaviours such as lexical variables. In any case it only warns in
the less likely package-then-lexical order, and not in the more likely
lexical-then-package order which was the original intent of the
discussion leading up to its invention.
We decided to remove it https://github.com/Perl/perl5/pull/21915#issuecomment-1998021478
I have left the changes to t/op/attrproto.t and t/op/lexsub.t in place
because those were just renames for something that made debugging the
tests confusing. They're not directly related to this warning, so should
remain.
This was a short-lived experimental feature intended to implement
removal of lexical symbols, in order to provide syntax like
`no builtin ...` or to remove implied imported builtins on a change of
prevailing `use VERSION`. The model of removing a lexical has proven to
be too subtle and complex to implement as well as raising various
awkward questions about the semantics, so we decided to remove it again
in Perl 5.39.8. There is now no longer any code that uses
PADNAMEf_TOMBSTONE.
As PADNAMEf_TOMBSTONE was only added in earlier in the 5.39.x developent
series, there is no need to retain the constants in .h files for
compatibility or to reserve the numbers for them. They have never
appeared in a stable release of Perl.
This previously put the same CV into the inner pad, so on a
recursive call into the owning sub, from this sub, this CV would
still be active, and the attempt to clone into the still busy CV
would throw an error.
Fixes#18606
When adding a tombstone entry to the pad, there's no need to use a blank
SV for its pad entry, as it will never be used for anything.
This does now mean that pad slots whose names start '&' could now become
NULL, so downstream modules that try to inspect the pad should be a bit
more careful when looking, to see if it is a tombstone. If this commit
proves problematic for CPAN modules, we could undo it and leave all the
pad slots as blank SVt_NULL instead, at a slight increase in memory
usage.
But they do need CvOUTSIDE() for eval-in-package-DB's scope
magic to work correctly.
This also incidentally fixes a TODO Deparse, since the CvOUTSIDE
is now available
Fixes#19370 aka rt89544
This breaks #11286, but I don't think that's fixable without breaking
eval-in-DB's special scope behaviour.
This reverts (most of) commit a0d2bbd5c47035a4f7369e4fddd46b502764d86e.
A pad entry with this flag means that we should consider the name does
not exist. If we find that name on lookup, return NOT_IN_PAD instead.
This will be used for implementing the unexport version of lexical
imports used by `use builtin`, allowing `no builtin ...` to remove pad
entries again.
Traditionally, the @_ AV has been marked as AvREAL_off(), but AvREIFY_on().
This commit changes it so that on PERL_RC_STACK builds, @_ is AvREAL().
This will mean that when the stack is ref-counted, the stack frame can
be directly moved to @_ while maintaining the correct ref count for each
argument (in the same way that !AvREAL() worked well with a
non-ref-counted stack).
Note that the stack will not actually be reference-counted for a few
more commits yet. In the meantime, this commit allows for that by
bumping up the reference count of SVs being transferred from the stack
to @_. This extra step will soon be skipped.
Fixes#21067
When an instance of a closure is created, the pad entries for the
cloned sub are copied (S_clone_sv_pad()) from either the prototype
sub (for lexicals belonging to the sub) or from the context (for
lexicals from outside
the sub).
This doesn't happen for our variables, instead the cloned sub has
these pad entries set to NULL.
This isn't an issue at runtime since references to lexical our
sub/variables are compiled into GV or GVSV ops.
cv_undef_flags() assumed this these entries were non-NULL for all
lexical subs.
Fix by checking if the entry is an our sub and the CV being freed is
a clone, if so, skip the accesses to the NULL pad entry.
Added an assert to the new branch to ensure any changes in the above
results in an early failure here and hopefully a fix.
* Free the attrlist OP fragment when applying class or field attribute
* Free the OP_PADxV ops we only use to get the pad index out for
fieldvar declarations
* Add a refcount to the `struct padname_fieldinfo` to keep track of its
capture in inner closures so it can be freed at the right time
* Free the class-related fields out of HvAUX
* Free the actual ObjectFIELDS() array when destroying an object instance
* Dup fieldinfo->paramname at sv_dup() time / free it at free time
Adds a new experimental warning, feature, keywords and enough parsing to
implement basic classes with an empty `new` constructor method.
Inject a $self lexical into method bodies; populate it with the object instance, suitably shifted
Creates a new OP_METHSTART opcode to perform method setup
Define an aux flag to remark which stashes are classes
Basic implementation of fields.
Basic anonymous methods.
In GH 20435 many typos in our C code were corrected. However, this pull
request was not applied to blead and developed merge conflicts. I
extracted diffs for the individual modified files and applied them with
'git apply', excepting four files where patch conflicts were reported.
Those files were:
handy.h
locale.c
regcomp.c
toke.c
We can handle these in a subsequent commit. Also, had to run these two
programs to keep 'make test_porting' happy:
$ ./perl -Ilib regen/uconfig_h.pl
$ ./perl -Ilib regen/regcomp.pl regnodes.h
Implemented as a static inline function call, so that it can return the
padname pointer itself. This would allow use in expressions such as
ptr->field = PadnameREFCNT_inc(pn);
That makes it similar to the familiar SvREFCNT_inc() macro.
If this flag is set, then the CvXSUBANY(cv).any_sv pointer will have its
reference count decremented when the CV itself is freed. This is useful
for XS extensions that wish to store extra data in here. Without this
flag, such extensions have to resort to using magic with a 'free'
function to perform this work.
Rename the `PADNAMEt_*` constants to `PADNAMEf_*`, as they're supposed
to represent bitflags, not a type enumeration.
Also updated the `B` and `B::Deparse` modules to make use of the new modern
names (and avoid the old `SVpad_*` flags).
Also added `PADNAMEt_*` back-compat defines, guarded by `#ifndef PERL_CORE`
so as not to permit their use accidentally within perl core.
I believe the '!!' is somewhat obscure; I for one didn't know about it
for years of programming C, and it was buggy in one compiler, which is why
cBOOL was created, I believe. And it is graphically dense, and
generally harder to read than the cBOOL() construct.
This commit dates from before we moved to C99 where we can simply cast
to (bool), and cBOOL() has been rewritten to do that. But the vast
majority of code uses cBOOL(), and this commit brings the remainder of
the core .[ch] files into uniformity.
There's no efficient way to create a mortal SV of any type other than
SVt_NULL (via sv_newmortal). The options are either to do:
* SV* sv = sv_newmortal; sv_upgrade(sv, SVt_SOMETYPE);
but sv_upgrade is needlessly inefficient on new SVs.
* SV* sv = sv_2mortal(newSV_type(SVt_SOMETYPE)
but this will perform runtime checks to see if (sv) and if (SvIMMORTAL(sv),
and for a new SV we know that those answers will always be yes and no.
This commit adds a new inline function which is basically a mortalizing
wrapper around the now-inlined newSV_type.
When a function outside of sv.c creates a SV via newSV(0):
* There is a call to Perl_newSV
* A SV head is uprooted and its flags set
* A runtime check is made to effectively see if 0 > 0
* The new SV* is returned
Replacing newSV(0) with newSV_type(SVt_NULL) should be more efficient,
because (assuming there are SV heads to uproot), the only step is:
* A SV head is uprooted and its flags set
Anonymous constant subs were changed to be implemented internally as
XSUBs in 5.21.6, commit 1567c65ac069266bfe65959430c185babd476538.
This broke DEBUGGING perls running under -DXv which weren't taught
about the new implementation. In ed958fa3156084f3cf4d8c4768716d9e1a11ce91
strict.pm also was changed to use such subs, which then breaks many
uses of -DXv.
See t/run/switchDx.t for an example of code that would trigger this that
does not depend on strict.pm
This fixes the problem and adds a test for -Dx.
