| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous commits in this branch have brought literal code blocks
into the New World Order; now do the same for runtime blocks, i.e. those
needing "use re 'eval'".
The main user-visible changes from this commit are that:
* the code is now fully parsed, rather than needing balanced {}'s; i.e.
this now works:
my $code = q[ (?{ $a = '{' }) ];
use re 'eval';
/$code/
* warnings and errors are now reported as coming from "(eval NNN)" rather
than "(re_eval NNN)" (although see the next commit for some fixups to
that). Indeed, the string "re_eval" has been expunged from the source
and documentation.
The big internal difference is that the sv_compile_2op() and
sv_compile_2op_is_broken() functions are no longer used, and will be
removed shorty.
It works by the regex compiler detecting the presence of run-time code
blocks, and feeding the whole pattern string back into the parser (where
the run-time blocks are now seen as compile-time), then extracting out
any compiled code blocks and adding them to the mix.
For example, in the following:
$c = '(?{"runtime"})d';
use re 'eval';
/a(?{"literal"})\b'$c/
At the point the regex compiler is called, the perl parser will already
have compiled the literal code block and presented it to the regex engine.
The engine examines the pattern string, sees two '(?{', but only one
accounted for by the parser, and so constructs a short string to be
evalled: based on the pattern, but with literal code-blocks blanked out,
and \ and ' escaped. In the above example, the pattern string is
a(?{"literal"})\b'(?{"runtime"})d
and we call eval_sv() with an SV containing the text
qr'a \\b\'(?{"runtime"})d'
The returned qr will contain the new code-block (and associated CV and
pad) which can be extracted and added to the list of compiled code blocks
of the original pattern.
Note that with this scheme, the requirement for "use re 'eval'" is easily
determined, and no longer requires all the pp_regcreset / PL_reginterp_cnt
machinery, which will be removed shortly.
Two subtleties of this scheme are that normally, \\ isn't collapsed into \
for literal regexes (unlike literal strings), and hints aren't inherited
when using eval_sv(). We get round both of these by adding and setting a
new flag, PL_reg_state.re_reparsing, which indicates that we are refeeding
a pattern into the perl parser.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change the way that code blocks in patterns are parsed and executed,
especially as regards lexical and scoping behaviour.
(Note that this fix only applies to literal code blocks appearing within
patterns: run-time patterns, and literals within qr//, are still done the
old broken way for now).
This change means that for literal /(?{..})/ and /(??{..})/:
* the code block is now fully parsed in the same pass as the surrounding
code, which means that the compiler no longer just does a simplistic
count of balancing {} to find the limits of the code block;
i.e. stuff like /(?{ $x = "{" })/ now works (in the same way
that subscripts in double quoted strings always have: "$a{'{'}" )
* Error and warning messages will now appear to emanate from the main body
rather than an re_eval; e.g. the output from
#!/usr/bin/perl
/(?{ warn "boo" })/
has changed from
boo at (re_eval 1) line 1.
to
boo at /tmp/p line 2.
* scope and closures now behave as you might expect; for example
for my $x (qw(a b c)) { "" =~ /(?{ print $x })/ }
now prints "abc" rather than ""
* with recursion, it now finds the lexical within the appropriate depth
of pad: this code now prints "012" rather than "000":
sub recurse {
my ($n) = @_;
return if $n > 2;
"" =~ /^(?{print $n})/;
recurse($n+1);
}
recurse(0);
* an earlier fix that stopped 'my' declarations within code blocks causing
crashes, required the accumulating of two SAVECOMPPADs on the stack for
each iteration of the code block; this is no longer needed;
* UNITCHECK blocks within literal code blocks are now run as part of the
main body of code (run-time code blocks still trigger an immediate
call to the UNITCHECK block though)
This is all achieved by building upon the efforts of the commits which led
up to this; those altered the parser to parse literal code blocks
directly, but up until now those code blocks were discarded by
Perl_pmruntime and the block re-compiled using the original re_eval
mechanism. As of this commit, for the non-qr and non-runtime variants,
those code blocks are no longer thrown away. Instead:
* the LISTOP generated by the parser, which contains all the code
blocks plus OP_CONSTs that collectively make up the literal pattern,
is now stored in a new field in PMOPs, called op_code_list. For example
in /A(?{BLOCK})C/, the listop stored in op_code_list looks like
LIST
PUSHMARK
CONST['A']
NULL/special (aka a DO block)
BLOCK
CONST['(?{BLOCK})']
CONST['B']
* each of the code blocks has its last op set to null and is individually
run through the peephole optimiser, so each one becomes a little
self-contained block of code, rather than a list of blocks that run into
each other;
* then in re_op_compile(), we concatenate the list of CONSTs to produce a
string to be compiled, but at the same time we note any DO blocks and
note the start and end positions of the corresponding CONST['(?{BLOCK})'];
* (if the current regex engine isn't the built-in perl one, then we just
throw away the code blocks and pass the concatenated string to the engine)
* then during regex compilation, whenever we encounter a '(?{', we see if
it matches the index of one of the pre-compiled blocks, and if so, we
store a pointer to that block in an 'l' data slot, and use the end index
to skip over the text of the code body. Conversely, if the index doesn't
match, then we know that it's a run-time pattern and (for now), compile
it in the old way.
* During execution, when an EVAL op is encountered, if data->what is 'l',
then we just use the pad that was in effect when the pattern was called;
i.e. we use the current pad slot of the currently executing CV that the
pattern is embedded within.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit is a first step to making the handling of (/(?{...})/ more sane.
But see the big proviso at the end.
Currently a patten like /a(?{...})b/ is uninterpreted by the lexer and
parser, and is instead passed as-is to the regex compiler, which is
responsible for ensuring that the embedded perl code is extracted and
compiled. The only thing the quoted string code in the lexer currently
does is to skip nested matched {}'s, in order to get to end of the code
block and restart looking for interpolated variables, \Q etc.
This commit makes the lexer smarter.
Consider the following pattern:
/FOO(?{BLOCK})BAR$var/
This is currently tokenised as
op_match
(
op_const["FOO(?{BLOCK})BAR"]
,
$
"var"
)
Instead, tokenise it as:
op_match
(
op_const["FOO"]
,
DO
{
BLOCK
;
}
,
op_const["(?{BLOCK})"]
,
op_const["BAR"]
,
$
"var"
)
This means that BLOCK is itself tokenised and parsed. We also insert
a const into the stream to include the original source text of BLOCK so
that it's available for stringifying qr's etc.
Note that by allowing the lexer/parser direct access to BLOCK, we can now
handle things like
/(?{"{"})/
This mechanism is similar to the way something like
"abc $a[foo(q(]))] def"
is currently parsed: the double-quoted string handler in the lexer stops
at $a[, the 'foo(q(]))' is treated as perl code, then at the end control is
passed back to the string handler to handle the ' def'.
This commit includes a new error message:
Sequence (?{...}) not terminated with ')'
since when control is passed back to the quoted-string handler, it expects
to find the ')' as the next char. This new error mostly replaces the old
Sequence (?{...}) not terminated or not {}-balanced in regex
Big proviso:
This commit updates toke.c to recognise the embedded code, but doesn't
then do anything with it. The parser will pass both a compiled do block
and a const for each embedded (?{..}), and Perl_pmruntime just throws
away the do block and keeps the constant text instead which is passed to
the regex compiler. So currently each code block gets compiled twice (!)
with two sets of warnings etc. The next stage will be to pass these do
blocks to the regex compiler.
This commit is based on a patch I had originally worked up about 6 years
ago and has been sitting bit-rotting ever since.
|
| |
|
|
|
| |
A future commit will change the output for this test, so use another one
that generates a straight syntax error.
|
| |
|
|
|
| |
Commit 4de6d205aeab9ec737ca35ba4eb61f37cebefc55 failed to take into
consideration tr///.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we get this:
$ ./perl -Ilib -e '$@ = "3"; warn'
3 ...caught at -e line 1.
then we shouldn’t get this:
$ ./perl -Ilib -e '$@ = 3; warn'
Warning: something's wrong at -e line 1.
as the two scalars hold the same value.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
-$1 was treating $1 as a float even if the string consisted of an
integer, due to incorrect flag checks. It was doing the same things
with tied variables returning str+int dualvars.
Simply checking whether the privates flags consist solely of SVp_IOK
(which works for tie variables returning pure integers--so I wasn’t
entirely wrong in adding that logic a few commits ago), isn’t suffi-
cient. For gmagical variables that have already had get-magic called
on them, the private flags are equivalent to public flags for other
variables.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
$ ./perl -Ilib -Mutf8 -CO -le 'print -"3 apples"'
-3
$ ./perl -Ilib -Mutf8 -CO -le 'print -"3 μῆλα"'
-3 μῆλα
This has been this way since 5.10.1. In 5.10.0, it was consistent:
$ perl5.10.0 -Mutf8 -CO -le 'print -"3 apples"'
-3
$ perl5.10.0 -Mutf8 -CO -le 'print -"3 μῆλα"'
-3
But the worst part is that we get a non-numeric warning now for a
string operation:
$ perl5.10.1 -Mutf8 -CO -lwe 'print -"3 μῆλα"'
Argument "\x{33}\x{20}..." isn't numeric in negation (-) at -e line 1.
-3 μῆλα
This goes back to commit a43d94f2c089, which by itself looks perfectly
correct (I won’t quote the diff here, as it is long; but it doesn’t
touch pp_negate):
commit a43d94f2c089c6f14197795daeebb7835550a747
Author: Nicholas Clark <nick@ccl4.org>
Date: Mon Jan 7 18:24:39 2008 +0000
Don't set the public IV or NV flags if the string converted from has
trailing garbage. This behaviour is consistent with not setting the
public IV or NV flags if the value is out of range for the type.
p4raw-id: //depot/perl@32894
It seems that pp_negate was already buggy before that (or ‘validly’
assumed that numeric coercion would set public flags). And it looks
as though commit 8eb28a70b2e is at fault here.
It changed this:
$ perl5.6.2 -Mutf8 -lwe 'print -"ð"'
-ð
to this:
$ perl5.8.1 -Mutf8 -lwe 'print -"ð"'
Argument "\x{f0}" isn't numeric in negation (-) at -e line 1.
0
to comply with what happens when the UTF8 flag is not set. But it was
relying on bugs in sv_2iv, etc.
So, from 5.8.0 to 5.10.0 inclusive, unary negation prepends "-" if the
string begins with [A-Za-z], but from 5.10.1 onwards it behaves diffe-
rently depending on the internal UTF8 flag (even prepending "-" to
ASCII-only strings like "%apples" if the UTF8 flag is on).
This commit restores the 5.8.0-5.10.0 behaviour, which was at least
self-consistent.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Commit a5b92898 caused -"-10" to return 10, not "+10". But it wasn’t
working for magical variables.
SvIV_please_nomg was fixed recently for magical variables, but not
SvIV_please, so change pp_negate to use that.
(Ironically, SvIV_please has never called magic, so the
SvIV_please_nomg variant never needed to exist. So the two could
be merged.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I think it’s a bug that this prints 0:
$ ./perl -lIlib -MDevel::Peek -e '$x = "dogs"; 0+$x; Dump $x; print -$x'
SV = PVNV(0x802340) at 0x821b90
REFCNT = 1
FLAGS = (POK,pIOK,pNOK,pPOK)
IV = 0
NV = 0
PV = 0x301620 "dogs"\0
CUR = 4
LEN = 16
0
This variable is a string, not a number. The number 0 is just a
cached value. It lacks the IOK flag precisely because the IV is not
representative of the actual value of the scalar.
This logic here is a little bit odd:
if( !SvNIOK( sv ) && looks_like_number( sv ) ){
SvIV_please( sv );
}
if ((flags & SVf_IOK) || ((flags & (SVp_IOK | SVp_NOK)) == SVp_IOK)) {
SvIV_please sets the flags on sv but then they are ignored when check-
ing for integrality.
To fix the bug mentioned above, I had to change this logic to use sv
directly, rather than the saved flags.
That meant that this bug was also fixed at the same time, since the
integer code is no longer bypassed when it is SvIV_please that sets
the integer flags:
$ ./perl -Ilib -le 'print -97656250000000000'
-97656250000000000
$ ./perl -Ilib -le 'print -"97656250000000000"'
-9.765625e+16
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Numeric ops were not taking magical variables into account. So $1 (a
magical variable) would be treated differently from "$1" (a non-magi-
cal variable0.
In determining whether to use an integer operation, they would call
SvIV_please_nomg, and then check whether the sv was SvIOK as a result.
SvIV_please_nomg would call SvIV_nomg if the sv were SvPOK or SvNOK.
The problem here is that gmagical variables are never SvIOK, but
only SvIOKp.
In fact, the private flags are used differently for gmagical and non-
magical variables. For non-gmagical variables, the private flag indi-
cates that there is a cached value. If the public flag is not set,
then the cached value is imprecise. For gmagical variables, imprecise
values are never cached; only the private flags are used, and they are
equivalent to the public flags on non-gmagical variables.
This commit changes SvIV_please_nomg to take gmagical variables
into account, using the newly-added sv_gmagical_2iv_please (see the
docs for it in the diff). SvIV_please_nomg now returns true or
false, not void, since a subsequent SvIOK is not reliable. So
‘SvIV_please_nomg(sv); if(SvIOK)’ becomes ‘if(SvIV_please_nomg(sv))’.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pp_warn was checking flags before calling get-magic, resulting in sev-
eral bugs that I fixed all at once::
• warn now calls get-magic exactly once on its argument, when there
is just one argument (it always worked correctly for multiple)
[perl #97480].
• warn calls get-magic exactly once on $@ when falling back to it,
instead of zero times.
• A tied variable returning an object that stringifies as an empty
string is no longer ignored if the tied variable was not ROK
before FETCH.
• A tied $@ containing a string, or $@ aliased to $1, is no
longer ignored.
• A tied $@ that last returned a reference but will return a string on
the next FETCH now gets "\t...caught" appended.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See also the previous commit.
2dd78f96 added the ‘Undefined top format called’ message for those
cases where a GV doesn’t have a name. That was a bug that used to
happen with *{$io}, which can’t happen any more.
The code that 2dd78f96 added ended up changing a zero-length name to
be treated the same way as no name. It also checked the length by
cheating and checking the first character instead.
Now that we have support for embedded nulls, that logic ends up wrong
for names like "\0foo". And there is no need to treat "" differently
from "foo" anyway.
So this patch restores things the way they were before 2dd78f96.
It also improves the tests for ‘Undefined format’.
Writing tests for ‘Undefined top format’ was quite painful, as that
error seems to leave the internal state out of synch. I suspect
PL_formtarget needs to be localised, or the error just needs to come
earlier in pp_leavewrite. But I’ll save that for later, or for Dave
Mitchell. :-)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit:
commit 2dd78f96d61cc6382dc72214930c993567209597
Author: Jarkko Hietaniemi <jhi@iki.fi>
Date: Sun Aug 6 01:33:55 2000 +0000
Continue fixing the io warnings. This also
sort of fixes bug ID 20000802.003: the core dump
is no more. Whether the current behaviour is correct
(giving a warning: "Not a format reference"), is another matter.
p4raw-id: //depot/perl@6531
added a check to see whether the format GV’s name is null, and, if
so, it dies with ‘Not a format reference’. Before that, that message
occurred only for lack of a GV.
The bug mentioned is now #3617, involving write(*STDOUT{IO}). write
puts an implicit *{} around its argument.
*{$io} has historically been very buggy in its stringification, so
this patch seems to have been working around that bugginess, by fall-
ing back to the ‘Not a format reference’ error if the name couldn’t be
determined for ‘Undefined format "foo" called’.
*{$io} was fixed once and for all in 5.16. It now stringifies as
*foopackage::__ANONIO__.
I don’t think producing a completetly different error based on the
name of the GV (whether it’s "foo" or "") is correct at all. And the
patch that made it happen was just a fix for a crash that can’t hap-
pen any more.
So the only case that should produce ‘Not a format reference’ is that
in which there is no format GV (fgv).
I can prove that fgv is always set (see below), and has been at least
since 5.000, so that ‘Not a format reference’ actually could never
occur before 2dd78f96d61c. (Actually, XS code could set PL_defoutgv
to null until the previous commit, but everything would start crashing
as a result, so it has never been done in practice.)
gv_efullname4 always returns a name, so checking SvPOK(tmpsv) is
redundant; checking whether the string buffer begins with a non-null
char is not even correct, as "\0foo" fails that test.
Proof that fgv is always set:
The current (prior to this commit) code in pp_enterwrite is like this:
if (MAXARG == 0) {
gv = PL_defoutgv;
EXTEND(SP, 1);
}
else {
gv = MUTABLE_GV(POPs);
if (!gv)
gv = PL_defoutgv;
}
If the stack value is null (which actually can’t happen), PL_defoutgv
is used. PL_defoutgv can’t be null.
At this point, gv is set to something non-null.
io = GvIO(gv);
if (!io) {
RETPUSHNO;
}
Here we only set fgv to IoFMT_GV(io) if it is non-null. Otherwise we
use gv, which we know is non-null.
if (IoFMT_GV(io))
fgv = IoFMT_GV(io);
else
fgv = gv;
|
| | |
|
| |
|
|
|
| |
In newer versions of GNU/kFreeBSD, linuxthreads supports POSIX semantics;
include a version check in t/op/getpid.t accordingly.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Calling HvNAME_HEK on something that is not a hash will result in a
crash if it happens to have the SvOOK flag on, because then it tries
to read to the end of HvARRAY, which may not even be a valid pointer.
This can happen with this convoluted test case:
{ package foo; sub bar { main::bar() } }
sub bar {
delete $::{"foo::"};
my $x = \($1+2);
my $y = \($1+2); # this is the one that reuses the mem addr, but
my $z = \($1+2); # try the others just in case
s/2// for $$x, $$y, $$z; # now SvOOK
warn scalar caller
};
foo::bar
This commit only partially fixes ticket #113486, by eliminating
the crash. We still have the problem of an unrelated stash reus-
ing the SV.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
POSIX allows one to use kill 0, PPID to detect if a process exists.
(Strictly that the current process is permitted to signal it, which is the
case here). If the system is sufficiently POSIXy, use kill 0, PPID to detect
that the parent has terminated, instead of just sleeping and hoping for the
best.
(Strictly to ensure the test terminates, there is still a race condition,
but if your test system is so loaded that a process takes more than 10
seconds to terminate, you've likely got bigger problems you need to address
first.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously t/op/getppid.t used sleep calls in the child and grandchild to
(attempt to) sequence actions between them. This was a subtle race condition,
which could come unstuck on busy systems causing spurious test failures.
Instead use EOF on pipes as a cheap portable way to synchronise between
processes. This eliminates one sleep call completely. Unfortunately, we can't
completely eliminate the other, as the grandchild spots that the child's
exit has closed the pipe *before* the child completely exits. Hence retain
the sleep to (usually) give time for the child to completely exit. This
reduces the race condition to "sleep 2" vs "child finishes exiting", which
is much less than the previous race condition of "sleep 2" vs "child does
everything from returning from fork to exiting".
|
| |
|
|
| |
It shouldn't happen, but the diagnostics will be useful if does.
|
| |
|
|
|
|
| |
These automatically give diagnostics on failure, allowing the elimination
of two explicit calls to diag(). Also split one ok(... && ...) test into
two.
|
| |
|
|
| |
Previously the test was "is it greater than 1?"
|
| |
|
|
|
| |
This avoids needing to skip the two tests if t/TEST is a symlink, which is
the case when building with -Dmksymlinks.
|
| |
|
|
|
|
| |
The readonly file tests aren't worried about the file's length, and the
zero-length file tests aren't concerned about whether it's writable, so it's
possible to use the same file in both tests.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Only attempted to change the effective user ID if the test is running as
root. Don't bother consulting $Config to see whether assigning to $> is going
to work - just try it in an eval, and skip if it didn't. Only restore $> if
we know we changed it, and as we only change it from root, we already know
which value to restore it to.
The previous code to check $Config{d_seteuid} was incomplete, as it should
also have been checking for $Config{d_setreuid} and $Config{d_setresuid}, as
$> can use any of these.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This code has got excessively hairy. Originally, t/op/filetest.t was added
to test that various file test operators worked as expected. (Commit
42e55ab11744b52a in Oct 1998.) It used the file t/TEST and the directory
t/op for targets. To test that read-only files were detected correctly, it
would chmod 0555 TEST to set it read only.
The test would fail if run as root, because root can write to anything. So
logic was added to set the effective user ID to 1 by assigning to $> in an
eval (unconditionally), and restoring $> afterwards. (Commit 846f25a3508eb6a4
in Nov 1988.) Curiously, the restoration was done after the test for
C<-r op>, rather than before it.
Most strangely, a skip was then added for the C<-w op> test based on
$Config{d_seteuid}. The test runs after $> has been restored, so should have
nothing to do with setuid. It was added as part of the VMS-related changes of
commit 3eeba6fb8b434fcb in May 1999. As d_seteuid is not defined in VMS, this
makes the test skip on VMS.
Commit 15fe5983b126b2ad in July 1999 added a skip for the read-only file
test if d_seteuid is undefined. Which is actually the only test where having
a working seteuid() *might* matter (but only if running as root, so that $>
can be used to drop root privileges).
Commit fd1e013efb606b51 in August 1999 moved the restoration of $> earlier,
ahead of the test for C<-r op>, as that test could fail if run as root with
the source tree unpacked with a restrictive umask. (Bug ID 19990727.039)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 07055b4c536 (Support named closures) added code to make refer-
encing a closure prototype clone the prototype. Commit 28757baaaeaa
(inseparable changes from patch from perl5.003_19 to perl5.003_20),
which includes ‘Subject: Rescind named closures’ in its log, appar-
ently did not rescind ‘named closures’ completely, leaving a line of
code that was completetly unused and untested, until just now when I
tried doing something bizarre to see whether some other piece of code
was buggy. This wasn’t what I expected. :-)
$ ./perl -Ilib -e 'sub MODIFY_CODE_ATTRIBUTES{\&{$_[1]};} my $x; +sub :bar{$x}'
Assertion failed: (depth || SvTYPE(proto) == SVt_PVFM), function Perl_cv_clone, file pad.c, line 1890.
Abort trap
|
| |
|
|
|
| |
This updates the editor hints in our files for Emacs and vim to request
that tabs be inserted as spaces.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unless called as &CORE::undef (without parentheses) after @_ has been
set to \*_, it leaves @_ in the ARRAY slot.
This is an implementation detail leaking through.
pp_entersub temporarily aliases @_ to a new array, which is restored
to its previous value on sub exit.
Since &CORE::undef is a perl sub with an op tree containing
an undef op,
$ ./perl -Ilib -MO=Concise,CORE::undef -e '\&CORE::undef'
CORE::undef:
3 <1> leavesublv[1 ref] K/REFC,1 ->(end)
2 <1> undef sKP/1 ->3
1 <$> coreargs(IV 44) s ->2
-e syntax OK
the undef op runs while @_ is localised.
So we should un-localise @_ if we detect that case.
Doing this in pp_coreargs might be a bit of a hack, but it’s less
code than rewriting &CORE::undef as an XSUB, which would be the
other option.
Either way, we need a special case, since undef is the only named op
that touches the ARRAY slot of the glob passed to it.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the error message, we can’t say ‘&CORE::undef operator’, so we
should be using the op name, rather than the op description.
Instead of using OP_NAME(PL_op->op_next), which would expand to
PL_op->op_next->op_type == OP_CUSTOM
? XopENTRY(Perl_custom_op_xop(aTHX_ PL_op->op_next), xop_name)
: PL_op_name[PL_op->op_next->op_type]
we can simply use PL_op_name[opnum], which should be quicker.
pp_undef can already handle nulls on the stack.
There is one remaining problem. If &CORE::undef(\*_) is called, *_
will be undefined while @_ is localised during the sub call, so it
won’t have the same effect as undef *_. I don’t know whether this
should be considered a bug or not, but I could solve it by making
pp_undef an XSUB.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I added a special case for OP_GLOB to pp_coreargs, since glob does not
have the u flag in regen/opcodes; hence PL_opargs[opnum] & OA_DEFGV is
false, even though glob does imply $_.
Adding the flag to regen/opcodes is not so simple, as the code in
ck_fun that adds the DEFSV op does not account for list ops, but
leaves op_last unchanged.
Changing ck_fun to account requires adding more code than this special
case in pp_coreargs.
OPf_SPECIAL indicates that glob was called with the CORE:: prefix.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Instead of skipping positive keywords (those that cannot be over-
ridden) because of their positivity, list them explicitly in the
skip list.
This will allow them to be removed one by one.
|
| |
|
|
|
|
|
|
| |
Instead of skipping positive keywords (those that cannot be over-
ridden) because of their positivity, list them explicitly in the
skip list.
This will allow them to be removed one by one.
|
| |
|
|
|
|
|
|
|
|
| |
‘Positive’ means having a + before it in regen/keywords.pl; i.e., key-
words that cannot be overridden.
Since all keywords are going to be added as subs to the CORE:: name-
space, with prototypes wherever they can apply, it makes sense to
return prototypes for all that can have them, which turns out to be
only a handful.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We are deprecating literal left braces in regular expressions. The 5.16
delta announced that this is coming.
This commit causes a warning to be raised when a literal "{" is
encountered. However, it does not do this if the left brace is at the
beginning of a construct. Such a brace does not cause problems for us
for our future use of it for other purposes, as, for example in things
like \b{w}, and there were a large number of core tests that failed
without this condition.
I didn't mention this exception in the diagnostic. We may choose to
forbid it everywhere, and we certainly want to discourage its use
everywhere. But this commit gets the essential components in early in
5.17, and we can tighten it up later if we decide to.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Nigel Sandever said:
> The error message produced by the following snippets is very unhelpful:
>
> c:\>perl -wle"print unpack 'v/a*', qq[a]"
> '/' must follow a numeric type in unpack at -e line 1.
>
> c:\>perl -wle"print unpack 'v/a*', ''"
> '/' must follow a numeric type in unpack at -e line 1.
>
> c:\>perl -wle"print unpack 'v/a*', ' '"
> '/' must follow a numeric type in unpack at -e line 1.
The "problem" is that the data string is too short. But
unpack doesn't generate a warning (or croak) in this case
for simple patterns:
mhx@r2d2 $ perl -MData::Dumper -we'print Dumper([unpack "n", "a"])'
$VAR1 = [];
So, I'd say your code should just behave in exactly the
same way. No warning, no return values.
|
