| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
The files should be named t/tmp*, to fall under .gitignore and be ignored
by podcheck.
|
|
|
|
|
|
| |
$@ could be clobbered by source filters, screwing up the reporting of
errors in the filtered source. Prevent this by localising $@ around
each call to a source filter. Fixes [perl #38920].
|
| |
|
|
|
|
|
|
|
|
|
|
| |
These two tests are not using test.pl
and do not need to load any special file.
No need for fancy setup in BEGIN, all the most
we cannot use the generic set_up_inc helper.
Simply remove the useless BEGIN block.
|
|
|
|
| |
Test plan should not be declared at compile time
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The:
d = skipspace(d);
can reallocate linestr in the test case, invalidating s. This would
end up in PL_bufptr from the embedded (PL_bufptr = s) in the TOKEN()
macro.
Assigning s to PL_bufptr and restoring s from PL_bufptr allows
lex_next_chunk() to adjust the pointer to the reallocated buffer.
|
|
|
|
|
|
|
| |
In the test case, scan_ident() ends up fetching another line
(updating PL_linestart), and since in this case we don't
successfully parse ${identifier} s (and PL_bufptr) end up being
before PL_linestart.
|
|
|
|
|
|
| |
This code point is no longer legal on such builds. We need to use this
code point to trigger the bug, so can't lower it to work on those
builds.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts the two related commits
51099b64db323d0e1d871837f619d72bea8ca2f9 (partially)
13f4dd346e6f3b61534a20f246de3a80b3feb743 (entirely)
I was in the middle of a long branch dealing with this and related
issues when these were pushed to blead. It was far easier for me to
revert these at the beginning of my branch than to try to rebase
unreverted. And there are changes needed to the approaches taken in the
reverted commits. A third related commit,
113b8661ce6d987db4dd217e2f90cbb983ce5d00, doesn't cause problems so
isn't reverted.
I reverted the second commit, then the first one, and squashed them
together into this one. No other changes were done in this commit.
The reason for the squashing is to avoid problems when bisecting on a
32-bit machine. If the bisect landed between the commits, it could show
failures. The portion of the first commit that wasn't reverted was the
part that was rendered moot because of the changes in the meantime that
forbid bitwise operations on strings containing code points above
Latin1.
The next commit in this series will reinstate portions of these commits.
I reverted as much as possible here to make this reversion commit
cleaner.
The biggest problem with these commits, is that some Perl applications
are made vulnerable to Denial of Service attacks. I do believe it is ok
to croak when a program tries, for example, to do chr() of too large a
number, which is what the reverted commit does (and what this branch
will eventually reinstate doing). But when parsing UTF-8, you can't
just die if you find something too large. That would be an easy DOS on
any program, such as a web server, that gets its UTF-8 from the public.
Perl already has a means to deal with too-large code points (before
5.26, this was those code points that overflow the word size), and web
servers should have already been written in such a way as to deal with
these. This branch just adapts the code so that anything above IV_MAX
is considered to be overflowing. Web servers should not have to change
as a result.
A second issue is that one of the reasons we did the original
deprecation is so that we can use the forbidden code points internally
ourselves, such as Perl 6 does to store Grapheme Normal Form. The
implementation should not burn bridges, but allow that use to easily
happen when the time comes. For that reason, some tests should not be
deleted, but commented out, so they can be quickly adapted.
While working on this branch, I found several unlikely-to-occur bugs in
the existing code. These should be fixed now in the code that handles
up to UV_MAX code points, so that when we do allow internal use of such,
the bugs are already gone.
I also had researched the tests that fail as a result of the IV_MAX
restriction. Some of the test changes in these reverted commits were
inappropriate.
For example, some tests that got changed were for bugs that happen only
on code points that are now illegal on 32-bit builds. Lowering the code
point in the test to a legal value, as was done in some instances, no
longer tests for the original bug. Instead, where I found this, I just
skip the test on 32-bit platforms.
Other tests were simply deleted, where a lower code point would have
worked, and the test is useful with a lower code point. I retain such
tests, using a lower code point. In some cases, it was probably ok to
delete the tests on 32-bit platforms, as something was retained for a
64-bit one, but since I had already done the adaptive work, I retain
that.
And still other tests were from files that I extensively revamp, so I
went with the revamp.
The following few commits fix those as far as possible now. This is so
that the reversion of the tests and my changes are close together in the
final commit series. Some changes have to wait to later, as for those
where the entire test files are revamped, or when the deprecation
messages finally go away in the final commit of this series.
In cases where the message wording I was contemplating using conflicts
with the reverted commits, I change mine to use that of the reverted
commits.
|
|
|
|
|
|
|
|
|
| |
Commit v5.27.0-132-g13f4dd3 forbade out of range Unicode code points,
and fixed/removed tests that no longer apply.
However, this was probably only tested on a 64-bit platform. Several
tests now fail on 32-bit platforms, due to things like "\x{80000000}".
This commit fixes up those tests too.
|
|
|
|
|
| |
d7186add added a runperl() test that breaks command line length limits for
VMS. Switch to fresh_perl() instead, so the prog is put in a file for us.
|
|
|
|
|
| |
Sometimes it's useful to have test.pl around, but it seems inappropriate
to pollute the existing t/comp/parser.t with that.
|
|
|
|
| |
(the previous commit forgot to)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When constant-folding a range/flipflop construct, the op_next threading
of peephole optimisation caused multiple ops in the construct to have
a null op_next, because the final (and top-level) op in the construct
is a null op. This meant that simple restoration of the top-level
op's op_next after execution wouldn't get it back into a fit state
to be composed with other ops. In the event that the range construct
couldn't be constant-folded this made it compile to a broken optree.
If it couldn't be constant-folded but could actually be executed, for
example because it generated a warning, this meant the brokenness would
be encountered at runtime. Execution would stop after the range op,
because of the null op_next.
To avoid this, temporarily mark the null op as a custom op during the
peephole optimisation that supports the execution for constant-folding.
This prevents it being op_next-threaded out, so simple op_next restoring
then works. If the constant-folding is aborted, it compiles to an
operational optree. However, the suppression of duplicate peephole
optimisation means that the null op is never ultimately threaded out
as it should be. For the time being, this stands as a cost of failed
constant-folding of range constructs.
Fixes [perl #130639].
|
|
|
|
|
|
|
|
|
| |
When the attempt to constant-fold a list generates an error, that
error should not be signalled at compile time, but merely abort the
attempt at constant folding, so that the error will occur naturally
at runtime. This is achieved by wrapping the compile-time execution in
gen_constant_list() in a fake eval block. This brings it in line with
the scalar fold_constants(). Fixes [perl #129320].
|
|
|
|
|
| |
It is clearer to show that these characters which are sometimes meta and
sometimes literal are meant to be taken literally here.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts v5.25.7-60-gb2c9b6e and adds a test.
In that previous commit of mine, for efficiency I changed it so that it
checked and extended the parser stack only after every reduce rather than
every shift, but when it did check, it extended it by at least 15 slots to
allow for all the elements of the longest possible rule to be shifted.
Turns out this was bad reasoning. The following type of code can shift
indefinitely without ever reducing:
[{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{
|
|
|
|
|
| |
require calls now require ./ to be prepended to the file since . is no
longer guaranteed to be in @INC.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When parsing the special ${var{subscript}} syntax, the lexer notes
that the } matching the ${ will be a fake bracket, and should
be ignored.
In the case of ${p{};sub p}() the first syntax error causes tokens to
be popped, such that the } following the sub declaration ends up being
the one treated as a fake bracket and ignored.
The part of the lexer that deals with sub declarations treats a ( fol-
lowing the sub name as a prototype (which is a single term) if signa-
tures are disabled, but ignores it and allows the rest of the lexer to
treat it as a parenthesis if signatures are enabled.
Hence, the part of the parser (perly.y) that parses signatures knows
that a parenthesis token can only come after a sub if signatures are
enabled, and asserts as much.
In the case of an error and tokens being discarded, a parenthesis may
come after a sub name as far as the parser is concerned, even though
there was a } in between that got discarded. The sub part of the
lexer, of course did not see the parenthesis because of the interven-
ing brace, and did not treat it as a prototype. So we get an asser-
tion failure.
The simplest fix is to loosen up the assertion and allow for anomalies
after errors. It does not hurt to go ahead and parse a signature at
this point, even though the feature is disabled, because there has
been a syntax error already, so the parsed code will never run, and
the parsed sub will not be installed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When converting an op into an lvref op (the rv2av in \(@_)=... gets
converted while the refgen gets nulled), if we reject the op as a
valid one for refaliasing we should not go ahead and convert it. It
we do convert it (as we were doing), then we may convert an op that
uses op_targ for auxiliary information into one that uses it as a pad
offset. When freeing the op, we will then be reading a ‘random’ off-
set in the pad and trying to free the SV. That pad entry may not even
be within the pad.
In the specific case of entereval, op_targ holds the hints, and the
larger the value of $^H, the more likely it is to crash. So
BEGIN{$^H=-1}\eval=... will crash.
|
|
|
|
|
|
|
|
|
|
|
| |
RT #128952
In
eval "q" . chr(100000000064);
generating the error message C<Can't find string terminator "XXX"'>
was overrunning a buffer designed to hold a single utf8 char, since
it wasn't allowing for the \0 at the end.
|
|
|
|
|
| |
Some of this is ugly, but that’s because I wrote a one-liner to do
it. It’s good enough for practical purposes.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
keys(%h) was special in that it did not use the same code path as
other ops that distinguish between scalar and list lvalue context.
Consequently, some scalar lvalue contexts worked:
keys %h = 3;
${\scalar keys %h} = 3;
sub { $_[0] = 3 }->(scalar keys %h);
foreach(scalar keys %h) { $_ = 3 }
grep { $_ = 3 } scalar keys %h;
substr keys %h, 0, = 3;
while others did not:
keys %h .= 0;
read FH, keys %h, 0;
Fixing other bugs in the same code paths without breaking keys (or
adding *more* exceptions) is harder to do if keys is not consistent.
So this commit allows .= and read to assign to keys, by using the same
internal code (scalar_mod_type) that determines whether %h assignment
is allowed. The logic is reversed (since %h is list-only and keys %h
is scalar-only), so where %h is a valid lvalue keys %h is not, and
vice versa.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Originally, 'require ::Foo::Bar' would try to load /Foo/Bar.pm.
The previous commit changed it so that ::Foo::Bar mapped to Foo::Bar,
and so loaded Foo/Bar.pm in the @INC path.
This commit takes the different approach of, instead of mapping, making
any bareword require that starts with '::' into an error instead.
It introduces a new error message:
$ perl -e'require ::Foo::Bar'
Bareword in require must not start with a double-colon: "::Foo::Bar"
$
See the thread at:
http://www.nntp.perl.org/group/perl.perl5.porters/2012/07/msg189909.html
( I originally used '"::"' rather than 'a double-colon', but that
made the message a bit unpenetrable:
Bareword in require must not start with "::": "::Foo::Bar"
)
|
|
|
|
|
|
|
|
|
| |
[ This is cherry-picked from a branch Nicholas wrote 4 years ago, but
which was never merged. In the meantime it was agreed that 'require
::foo' should die instead of doing 'require foo'; but I've pulled it in
anyway as an interim commit, to make later cherry-picks easier. The die
will come in a later commit.
]
|
|
|
|
|
|
|
| |
This just disables the syntax and modifes the tests. The underlying
infrastructure has not been removed yet.
I had to change a couple of tests in cpan/.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
RT #123475
Commit e41e9865be5555 (to fix [perl #123062]) restricted the types of
args allowed for a function with a '&' prototype - previously it allowed
array refs and the like. It also removed undef, so this was now a
compile-time error:
sub foo (&) {...}
foo(undef)
However, some CPAN code used the idiom register_callback(undef) to
explicitly disable a registered callback.
So re-allow an explicit undef.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
v5.21.4-416-g73f4c4f converted (among other things) stringify(join(...))
into just join(...). It asserted that the stringify didn't have any extra
children, which it won't normally do, since in something like "@a-" the
elements of the stringify get bundled up into a single tree of concats
etc, and stringify just sees a single top-level join or concat or
whatever. However during error recovery weird stuff can get left on the
stack.
So rather than asserting no more kids, skip the optimisation if there are
more kids.
|
|
|
|
|
|
|
| |
For some reason the argument to require v5.6 has the NOK flag on,
but the parenthesized version lacks that flag, so the code added in
v5.21.3-504-ged6f447 to precompute the hash was wrong, and caused
require(v5.6) to lose its vstringness.
|
| |
|
|
|
|
|
|
|
|
| |
// in the scope of lexical $_ gets the OPpTARGET_MY flag set. If it
is used as an operand to smartmatch, it gets converted to a qr op.
There is no need to turn off the flag, since it is harmless at run
time. But we need to allow the flag on this op type to avoid asser-
tion failures when it is freed.
|
|
|
|
|
|
| |
Replace the stricter MAX_PORTABLE_UTF8_TWO_BYTE check with a looser
MAX_UTF8_TWO_BYTE check, else we can't correctly convert codepoints in
the range 0x400-0x7ff from utf16 to utf8 on non-ebcdic platforms.
|
|
|
|
|
|
|
|
| |
ck_grep calls ck_fun, which sets the lower private bits to indicate
the number of operands. ck_grep usually undoes that, by clobbering
op_private completetly. If an error has occurred, it doesn’t, so we
may fail an assertion if the lower bits are not expected to be set on
mapstart and grepstart.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As of v5.13.6-130-geae48c8, the block consists solely of a
nextstate op.
The code in ck_eval that distinguished between eval-block and eval-
string was checking the type of the kid op (looking for lineseq or
stub) instead of simply checking the type of the op itself (entertry/
entereval).
The lexer was already making the distinction between the two but op.c
was ignoring the information provided by the lexer.
Usually
entertry(unop)
kid
gets converted into
leavetry
entertry(logop)
kid
with the entertry reallocated as a larger-sized op, but that was not
happening. The peephole optimiser assumed it had happened, and fol-
lowed the cLOGOPo->op_other pointer, which is unrelated junk beyond
the end of the unop struct. Hence the crash.
|
| |
|
|
|
|
|
| |
I increased the skip count in 08b999a9 by mistake. For crashing bugs,
executing the code that would have crashed is sufficient to test it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
s/foo/bar/ tokenizes as something akin to subst("foo","bar") and the
resulting list op representing the contents of the parentheses is
passed to pmruntime as its expr argument.
If we have invalid code like s/${<>{})//, the bison parser will dis-
card invalid tokens until it finds something it can fall back to, in
an attempt to keep parsing (to report as many errors as possible).
In the process of discarding tokens, it may convert s/${<>{})//, which
the lexer emits like this:
PMFUNC ( $ { THING(readline) { } ) , "" )
into this:
PMFUNC ( $ { THING(readline) } ) , "" )
(or something similar). So when the parser sees the first closing
parentheses, it decides it has a complete PMFUNC(...), and the expr
argument to pmruntime ends up being an rv2sv op (the ${...}), not
a list op.
pmruntime assumes it is a list op, and tries to access its op_last
field, to find the replacement part; but rv2sv has no op_last field,
so this reads past the end of the op struct, usually into the first
pointer in the next op slot, which itself is an opslot pointer, not an
op pointer, so things really screw up.
If we check that the arguments to subst are indeed a list op first
before trying to extract the replacement part, everything works. We
get the syntax errors reported as expected, but no crash.
|
|
|
|
|
|
|
| |
Previously it would read and replace the previous item on the stack:
$ ./perl -le 'print "CORE::undef", prototype'
;\[$@%&*]
|
| |
|
| |
|
|
|
|
|
|
|
| |
The multideref assertions should allow the OPf_SPECIAL flag, because
an OP_GV that started out as OP_CONST and got converted in ck_rvconst
may have have OPf_SPECIAL set already. This flag is harmless on
OP_GV, so don’t bother turning it off.
|
|
|
|
|
| |
Type::Tiny was triggering this. The Type::Tiny failure was mention in
ticket #123213.
|
| |
|
|
|
|
|
|
|
|
| |
I enable PERL_DISABLE_PMC in a .h, not in CCFLAGS. CCFLAGS on Unix
typically has no -Ds in it, build options go into config.h, not
Config.pm's CCFLAGS. This change allows PERL_DISABLE_PMC option to pass
tests regardless of where it is defined. cpan/parent/t/parent-pmc.t is not
fixed by this patch.
|
|
|
|
|
|
|
|
|
| |
It was checking to see whether its argument were an entersub op (&foo
is indeed an entersub) and then wrapping it in refgen (\). But enter-
sub also covers &foo() and foo() and foo. op_lvalue checks whether
the OPf_STACKED flag is set and only turns it into rv2cv if it is not.
(Only &foo lacks that flag.) So I copied that logic into prototype
application.
|