| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
* Add feature, experimental warning, keyword
* Basic parsing
* Basic implementation as optree fragment
See also
https://github.com/Perl/perl5/issues/18504
|
|
|
|
|
| |
The specified commit fixed a bug by treating ($x, undef) on the LHS
as 2 scalars; this comment should have been updated to match.
|
|
|
|
| |
This disables use of bareword filehandles except for the built-in handles
|
|
|
|
| |
Fixes #18449
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This code would try to constant fold an op tree like
relop
+- null
+- constant
which would underflow the stack, potentially crashing perl.
This is intended as a quick fix rather than as a complete
solution.
Fixes #18380
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This feature allows documentation destined for perlapi or perlintern to
be split into sections of related functions, no matter where the
documentation source is. Prior to this commit the line had to contain
the exact text of the title of the section. Now it can be a $variable
name that autodoc.pl expands to the title. It still has to be an exact
match for the variable in autodoc, but now, the expanded text can be
changed in autodoc alone, without other files needing to be updated at
the same time.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Thus function has a couple a switches with
default:
NOT_REACHED; /* NOTREACHED */
but clang is complaining that the value returned by the function is
undefined if those default branches are taken, since the 'any' variable
doesn't get set in that path.
Replace the NOTREACHED with a croak("panic: ..."). It's possible (albeit
not intended) for Perl_custom_op_get_field() to be called with a 'field'
arg which triggers the default case. So if this ever happens, make it
clear that something has gone wrong, rather than just silently
continuing on non-debugging builds.
In any case, this shuts up clang.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This uses a new organization of sections that I came up with. I asked
for comments on p5p, but there were none.
|
|
|
|
|
| |
apidoc_section is slightly favored over head1, as it is known only to
autodoc, and can't be confused with real pod.
|
|
|
|
| |
These just refer to foo's pod, with an explanation of 'nocontext'
|
|
|
|
|
|
|
| |
I was never happy with this short form, and other people weren't either.
Now that most things are better expressed in terms of av_count, convert
the few remaining items that are clearer when referring to an index into
using the fully spelled out form
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GH #17816
This code:
my $x = 1;
print (($x, undef) = (2 => $x));
was printing "22" when it should have been printing "21".
An optimisation skips the 'common values on both sides' test
when the LHS of an assign only contains a single var; as the example
above shows, this is not sufficient.
This was broken by v5.23.1-202-g808ce55782
This commit fixes it by counting undef's on the LHS towards the var
count if they don't appear first.
|
|
|
|
|
|
| |
Like "indirect" this feature is enabled by default and enables the
perl4 hash-based multidimensional array emulation documented under
$; in perlvar.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #17871
The op slab allocator code made the assumption that since OP and
hence OPSLOT contain pointers, the base of each of those would be
an integral number of sizeof(pointer) (pointer units) from the
beginning of OPSLAB.
This assumption is non-portable, and broke calculating the location
of the slab based on the address of the op slot and the op slot offset
on m68k platforms.
To avoid that, this change now stores the opslot_offset as the
offset in pointer units from the beginning of opslab_slots rather
than from the beginning of the slab.
If alignment on a pointer boundary for OPs is required, the compiler
will align opslab_opslots and since we work in pointer units from there,
any allocated op slots will also be aligned.
If we assume PADOFFSET is no larger than a pointer and requires no
stricter alignment and structures in themselves have no stricter
alignment requirements then since we work in pointer units all core
OP structures should have sufficient alignment (if this isn't true,
then it's not a new problem, and not the problem I'm trying to solve
here.)
I haven't been able to test this on m68k hardware (the emulator I
tried to use can't maintain a network connection.)
|
|
|
|
|
| |
It only does anything under PERL_GLOBAL_STRUCT, which is gone.
Keep the dNOOP defintion for CPAN back-compat
|
|
|
|
|
|
|
|
|
|
|
| |
I realized as a result of fixing GH #17654, that the code didn't
properly decide if a tr/// can be done in-place on EBCDIC platforms.
Since we didn't have an EBCDIC smoker at the time, I couldn't be sure
that the fix actually worked. Now that we do have a smoker, I have
successfully tested it.
This patch is constructed so that the code generated on non-EBCDIC
platforms should not be changed by it.
|
|
|
|
|
| |
Mostly in comments and docs, but some in diagnostic messages and one
case of 'or die die'.
|
|
|
|
| |
This reverts commit f2f32cd638746f538da6db804dab6dd54e654f30.
|
|
|
|
| |
This reverts commit ad89278aa25475fb03971aec66692e18e35d9c07.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A tr/// can be done in-place if the target string doesn't contain a
character whose transliterated representation is longer than the
original. Otherwise, writing the new value would destroy the next
character we need to read.
In general, we can't know if a particular string contains such a
character without keeping a list of the problematic characters, and
scanning it ahead of time for occurrences of those. Instead, we
determine at compilation time if, for a given transliteration, if there
exists any possible target string that could have an overwriting
problem. If none exist, we edit in place. Otherwise, we first make a
copy.
Prior to this commit, the code failed to account for the case where the
rhs is shorter than the left, so that any unmatched lhs characters map
to the final rhs one. The reason the code didn't consider this is that
I didn't think of this possibility when writing it.
This fixes #17654 and #17643
|
|
|
|
|
| |
Sprinkle some dVAR pixie dust to fix recent bitrot on that build
configuration.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GH #15109, #17567
[ this commit was originally applied as v5.31.9-121-gfb8188b84d, but was
quickly reverted by v5.31.9-124-g6311900a66. I'm now -re-applying it,
but with a 'SAVEFREEOP(PL_curcop)' added, which was missing from the
original commit. ]
My original fix for this issue, v5.31.6-141-gf2f32cd638
made a shallow copy of &PL_compiling. However, for non-default
warning bits, this made two COPs share the malloced() cop_warnings,
and bad things ensured. In particular this was flagged up in:
GH #17567: "BBC: AYOUNG/OpenVZ-0.01.tar.gz"
The fix in this commit is to do a deep copy of the COP using
newSTATEOP().
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Optype appears to be almost completely unused, and on Win32 builds
we saw warnings from the cmpchain patches:
perly.y(1063) : warning C4244: 'function' : conversion from 'I32' to 'Optype', possible loss of data
perly.y(1065) : warning C4244: 'function' : conversion from 'I32' to 'Optype', possible loss of data
perly.y(1079) : warning C4244: 'function' : conversion from 'I32' to 'Optype', possible loss of data
perly.y(1081) : warning C4244: 'function' : conversion from 'I32' to 'Optype', possible loss of data
Reviewing the code I noticed that functions like Perl_newBINOP() have
an I32 type argument, and functions like OpTYPE_set() coerce such
arguments into type OPCODE:
#define OpTYPE_set(o,type) \
STMT_START { \
o->op_type = (OPCODE)type; \
o->op_ppaddr = PL_ppaddr[type]; \
} STMT_END
this patch changes the signature to the new cmpchain functions so that
they do they same, and change the type for storage for op_type values
to also use OPCODE like most of the other op.c code.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit fb8188b84d8a8f34f90aa9a8d9837892967f6b93.
Unfortunately this is causing some errors during global destruction
like:
Unbalanced string table refcount: (1) for "open_IN" during global destruction
It seems to be flapping, and recompiling Perl could see or not the
issue.
Upstream-URL: https://github.com/Perl/perl5/commit/fb8188b84d8a8f34f90aa9a8d9837892967f6b93
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GH #15109, #17567
My original fix for this issue, v5.31.6-141-gf2f32cd638
made a shallow copy of &PL_compiling. However, for non-default
warning bits, this made two COPs share the malloced() cop_warnings,
and bad things ensured. In particular this was flagged up in:
GH #17567: "BBC: AYOUNG/OpenVZ-0.01.tar.gz"
The fix in this commit is to do a deep copy of the COP using
newSTATEOP().
|
|
|
|
| |
Because it uses setjmp, is what g++ says
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
previously freed ops were stored as one singly linked list, and
a failed search for a free op to re-use could potentially search
that entire list, making freed op lookups O(number of freed ops),
or given that the number of freed ops is roughly proportional to
program size, making the total cost of freed op handling roughly
O((program size)**2). This was bad.
This change makes opslab_freed into an array of linked list heads,
one per op size. Since in a practical sense the number of op sizes
should remain small, and insertion is amortized O(1), this makes
freed op management now roughly O(program size).
fixes #17555
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In something like
local $~ = "$~X";
i.e. where localising a magic variable whose previous value should be
used as part of a string concat on the RHS, don't fold the assign into
the multiconcat op. Otherwise the code execution path looks a bit like:
local($~) = undef;
multiconcat($~, $~, "X");
[ where multiconcat's args are (target, arg1, arg2,....) ]
and thus multiconcat sees an undef arg.
By leaving the assign out of the multiconcat, code execution now looks
like
my $targ;
multiconcat($targ, $~, "X");
local($~) = $targ;
See http://nntp.perl.org/group/perl.perl5.porters/256898,
"Bug in format introduced in 5.27.6".
Although the bug only appears with magic vars, this patch pessimises
all forms of 'local $foo = "..."', 'local $foo{bar} = "..."' etc.
Strictly speaking the bug occurs because with 'local' you end up with
two SVs (the saved one and the one currently in the glob) which both
have the same container magic and where mg_set()ing one changes the
mg_get() value of the other. Thus, vars like $!. One of the two SVs
becomes an arg of multiconcat, the other becomes its target. Part of
localising the target SV (before multiconcat is called) wipes the value
of the arg SV.
|
|
|
|
| |
Mainly to avoid gcc warnings that found the logic too complex to follow.
|
|
|
|
|
| |
Balance the braces so we can bounce to matching braces for the rest
of S_pmtrans.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LGTM static code analysis identified declaration of 'o' in a scope where
a variable of the same name had already been declared in an enclosing
scope.
Simply renaming the variable within the inner scope did not work
(extensive segfaults). Tony Cook identified problem: In inner scope we
were using macro cLISTOPo, which implicitly modifies 'o'. Since
cLISTOPo is nothing more than macro cLISTOPx() with 'o' provided as the
argument, we can resolve the problem by using cLISTOPx() with a better
named variable -- in this case, 'child'.
Reference: https://lgtm.com/projects/g/Perl/perl5/snapshot/9b2028e54156e4dbcc7a57bbd72e1b00a2e0ce39/files/op.c?sort=name&dir=ASC&mode=heatmap#x9b0ebeab3d026530:1
|
| |
|
|
|
|
|
| |
Per discussion with Tony Cook, rename one variable used in commit
5162664ad5f (p.r. 17368) on Dec 16 2019.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GH #17301
The aux array in an OP_MULTIDEREF op consists of an action word
containing as many actions as will fit shifted together, followed by
words containing the arguments for those actions. Then another action
word, and so on. The code in S_maybe_multideref() which creates those
ops was reserving a new slot in the aux array for a new action word when
the old one became full. If it then turned out that no more actions
were needed, this extra slot was harmlessly filled with a zero.
However it turns out that the B::UNOP_AUX::aux_list() introspection
method would, under those circumstances, claim to have returned one
more SV on the stack than it actually had, leading to SEGVs etc.
I could have fixed aux_list() directly to cope with an extra null word,
but instead I did the more general fix of ensuring that
S_maybe_multideref() never adds an extra null word in the first place.
The test added to ext/B/t/b.t fails before this commit; the new test
in lib/B/Deparse.t doesn't, but was added for completeness.
|
| |
|
|
|
|
| |
The former is portable to different sized doubles.
|
|
|
|
|
|
|
| |
This replaces strchr("list", c) calls throughout the core. They don't
work properly when 'c' is a NUL, returning the position of the
terminating NUL in "list" instead of failure. This could lead to
segfaults or even security issues.
|
|
|
|
|
|
|
|
|
|
|
| |
This is useful in Devel::PPPort for generating its api-info data. That
useful feature of D:P allows someone to find out what was the first
release of Perl to have a function, macro, or flag. And whether using
ppport.h backports it further.
I went through apidoc.pod and looked for flags that were documented but
that D:P didn't know about. This commit adds entries for each so that
D:P can find them.
|
|
|
|
|
|
|
| |
This sub-optimal code has been reported by LGTM static code analysis.
There are actually two such instances very close to one another within
op.c. This commit handles only the first of them, renaming a variable
and regularizing the indents to make the relevant scope more self-evident.
|