| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This single op can, in some circumstances, replace the sequence of a
pushmark followed by one or more padsv/padav/padhv ops, and possibly
a trailing 'list' op, but only where the targs of the pad ops form
a continuous range.
This is generally more efficient, but is particularly so in the case
of void-context my declarations, such as:
my ($a,@b);
Formerly this would be executed as the following set of ops:
pushmark pushes a new mark
padsv[$a] pushes $a, does a SAVEt_CLEARSV
padav[@b] pushes all the flattened elements (i.e. none) of @a,
does a SAVEt_CLEARSV
list pops the mark, and pops all stack elements except the last
nextstate pops the remaining stack element
It's now:
padrange[$a..@b] does two SAVEt_CLEARSV's
nextstate nothing needing doing to the stack
Note that in the case above, this commit changes user-visible behaviour in
pathological cases; in particular, it has always been possible to modify a
lexical var *before* the my is executed, using goto or closure tricks.
So in principle someone could tie an array, then could notice that FETCH
is no longer being called, e.g.
f();
my ($s, @a); # this no longer triggers two FETCHES
sub f {
tie @a, ...;
push @a, 1,2;
}
But I think we can live with that.
Note also that having a padrange operator will allow us shortly to have
a corresponding SAVEt_CLEARPADRANGE save type, that will replace multiple
individual SAVEt_CLEARSV's.
|
| |
|
|
|
|
| |
This will be used for cloning a ‘my’ sub on scope entry.
I was going to use pp_padcv for this, but it would end up having a
top-level if/else.
|
| |
|
|
|
| |
This will be used for introducing ‘my’ subs on scope entry, by turning
off the stale flag.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
ck_chdir, added in 2006 (d4ac975e) duplicates ck_trunc, added in
1993 (79072805), except for a null op check which is harmless when
applied to chdir.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This takes the pessimistic approach of skipping it for any first argu-
ment that is not a plain non-magical PV, just in case there is a 'p'
or 'P' in the stringified form.
Otherwise it scans the PV for 'p' or 'P' and skips the folding if either
is present.
Then it falls through to the usual op-filtering logic.
I nearly made ‘pack;’ crash, so I added a test to bproto.t.
|
| | |
|
| |
|
|
|
|
| |
See the previous commit. The same applies here.
In short, this allows core_prototype and pp_coreargs to be simpler.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In regen/opcodes, we have some operators that use ck_fun and have R
for the argument. And there are some that use ck_lfun and have S for
the argument.
These both amount to more or less the same thing.
ck_fun/R goes through the OA_SCALARREF case in ck_fun, which calls
op_lvalue(scalar()) on the child op.
ck_lfun/S goes through the OA_SCALAR case in ck_fun, which calls
scalar(), and then ck_lfun sees to it that op_lvalue is called.
The only real difference is that the OA_SCALAR case makes sure there
are not too many arguments.
Since both core_prototype and pp_coreargs need special cases to deal
with OA_SCALAR that is really ‘supposed’ to be OA_SCALARREF, it
becomes simpler to add &CORE::undef if undef uses R. In that case,
we also have to put the argument-checking in the OA_SCALARREF, but we
make it conditional on the op being an undef op, for the sake of doing
one thing at a time. (This is a bit of a mess; see ticket #96006.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This goes all the way back to when perl 5.0 was being polished up.
The idea behind evalonce is that eval "constant string" should be
optimisable by being compiled ahead of time, just like eval { ... }.
But this could never work properly, because BEGIN blocks would only
fire once. Also, eval '$x .. $y' is an easy way to create two separ-
ate flip-flops. There are undoubtedly many other reasons why this
could never work.
So there is no reason to keep this comment any longer, as it is not
(or should not be) a to-do item.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Along with the simple_casefolding and full_casefolding features.
fc() stands for foldcase, a sort of pseudo case (like lowercase),
which is used to implement Unicode casefolding. It maps a string
to a form where all case differences are erased, so it's a
locale-independent way of checking if two strings are the same,
regardless of case.
This functionality was, and still is, available through the
regular expression engine -- /i matches would use casefolding
internally. The fc keyword merely exposes this for easier access.
Previously, one could attempt to case-insensitively test two strings
for equality by doing
lc($a) eq lc($b)
But that might get you wrong results, for example in the case of
\x{DF}, LATIN SMALL LETTER SHARP S.
|
| |
|
|
|
|
|
|
|
| |
Or potential lvalue context, like function calls.
The %n format code’s existence renders these two very much like func-
tion calls, as they can modify their arguments.
This allows sprintf("...%n", substr ...) to work.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
seek had the same bug as tell. Here is the commit message from
8dc99089, which fixed tell:
----------------------------------------------------------------------
Stop tell($glob_copy) from clearing PL_last_in_gv
This bug is a side effect of rv2gv’s starting to return an incoercible
mortal copy of a coercible glob in 5.14:
$ perl5.12.4 -le 'open FH, "t/test.pl"; $fh=*FH; tell $fh; print tell'
0
$ perl5.14.0 -le 'open FH, "t/test.pl"; $fh=*FH; tell $fh; print tell'
-1
In the first case, tell without arguments is returning the position of
the filehandle.
In the second case, tell with an explicit argument that happens to
be a coercible glob (tell has an implicit rv2gv, so tell $fh is actu-
ally tell *$fh) sets PL_last_in_gv to a mortal copy thereof, which is
freed at the end of the statement, setting PL_last_in_gv to null. So
there is no ‘last used’ handle by the time we get to the tell without
arguments.
This commit adds a new rv2gv flag that tells it not to copy the glob.
By doing it unconditionally on the kidop, this allows tell(*$fh) to
work the same way.
Let’s hope nobody does tell(*{*$fh}), which will unset PL_last_in_gv
because the inner * returns a mortal copy.
This whole area is really icky. PL_last_in_gv should be refcounted,
but that would cause handles to leak out of scope, breaking programs
that rely on the auto-closing ‘feature’.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This bug is a side effect of rv2gv’s starting to return an incoercible
mortal copy of a coercible glob in 5.14:
$ perl5.12.4 -le 'open FH, "t/test.pl"; $fh=*FH; tell $fh; print tell'
0
$ perl5.14.0 -le 'open FH, "t/test.pl"; $fh=*FH; tell $fh; print tell'
-1
In the first case, tell without arguments is returning the position of
the filehandle.
In the second case, tell with an explicit argument that happens to
be a coercible glob (tell has an implicit rv2gv, so tell $fh is actu-
ally tell *$fh) sets PL_last_in_gv to a mortal copy thereof, which is
freed at the end of the statement, setting PL_last_in_gv to null. So
there is no ‘last used’ handle by the time we get to the tell without
arguments.
This commit adds a new rv2gv flag that tells it not to copy the glob.
By doing it unconditionally on the kidop, this allows tell(*$fh) to
work the same way.
Let’s hope nobody does tell(*{*$fh}), which will unset PL_last_in_gv
because the inner * returns a mortal copy.
This whole area is really icky. PL_last_in_gv should be refcounted,
but that would cause handles to leak out of scope, breaking programs
that rely on the auto-closing ‘feature’.
|
| |
|
|
|
| |
After much alternation, altercation and alteration, __SUB__ is
finally here.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This function evaluates its argument as a byte string, regardless of
the internal encoding. It croaks if the string contains characters
outside the byte range. Hence evalbytes(" use utf8; '\xc4\x80' ")
will return "\x{100}", even if the original string had the UTF8 flag
on, and evalbytes(" '\xc4\x80' ") will return "\xc4\x80".
This has the side effect of fixing the deparsing of CORE::break under
‘use feature’ when there is an override.
|
| |
|
|
|
|
|
| |
Following Michael Schwern’s suggestion, here is a warning for those
hapless folks who use $[ for version checks.
It applies whenever $[ is used in one of: < > <= >=
|
| |
|
|
|
|
|
| |
Generate OP_IS_DIRHOP like other OP_IS_* macros,
use in gv.c:Perl_gv_add_by_type().
Modifies 'F' operand type to 'DF'.
This yields a micro-optimization.
|
| |
|
|
|
|
|
| |
other macros are written by regen/opcode.pl into opnames.h
Generate OP_IS_NUMCOMPARE the same way, and get a micro-optimization.
Adds a new 'S<' operand type for the numeric comparison ops.
Needs make regen.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
unpack is the only op that takes an implicit $_ for its second argu-
ment. (For others it’s the first.)
Instead of special-casing unpack with its own ck_ routine, we can sim-
ply modify the logic in ck_fun to apply OA_DEFGV to the first optional
argument, not just the first argument.
Currently OA_DEFGV is not set in PL_opargs[OP_UNPACK], which means the
automatically-generated prototype is ($;$), instead of ($_).
This commit sets the flag on the op, changes it to use ck_fun
directly, and updates ck_fun and the prototype-generation code accord-
ingly. I couldn’t put this in multiple commits, as the changes are
interdependent.
|
| |
|
|
| |
&CORE::foo subs will use this operator for sorting out @_.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since the argument is optional, we need a semicolon.
This commit accomplishes that by setting the OA_OPTIONAL flag for the
appropriate entries in PL_opargs. This should not affect anything
else, as ck_ftst (the check routine for [l]stat) doesn’t even look at
PL_opargs.
It also has to tweak the prototype-generation logic slightly, because
PL_opargs also has OA_DEFGV set.
I think this is insignificant enough not to warrant a delta entry.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
6a077020aea1c5f0 extended the OP_AELEMFAST optimisation to lexical arrays.
Previously OP_AELEMFAST was only used as an optimisation for OP_GV, which is a
PADOP/SVOP.
However, by reusing the same opcode, and signalling (pad) lexical vs package,
it introduced a myriad of special cases, because OP_PADAV is a BASEOP (not a
PADOP), whilst OP_AELEMFAST is a PADOP/SVOP (which is larger).
Using two OP numbers allows each variant to have the correct OP flags in
PL_opargs. Both can continue to share the same C code.
|
| |
|
|
| |
See ticket #80626.
|
| | |
|
|
|
Whilst it is possible to open regen/opcode.pl and parse it to find the __END__
token, it's not the cleanest approach.
|
