| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
(This sanity logic could migrated to Configure)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I was wrong in 9e319cc4f. postfix ++/-- writes to its return value
before reading its argument. If we optimise away the scalar
assignment in
$a = $b++;
(that’s what OPpTARGET_MY does), then $a gets written to before $b is
read. If $a and $b are the same, we get the wrong answer. This bug
has been present under ‘use integer’ since 5.6.0. I accidentally
extended it to non-integer ++/-- in 9e319cc4f.
(It’s not likely that someone will write $a = $b++, but it could hap-
pen inadvertently in more complex code.)
|
| | |
|
| |
|
|
| |
This makes the machine code smaller.
|
| |
|
|
| |
This shrinks the machine code slightly.
|
| |
|
|
|
|
|
|
|
| |
m//, s/// and y/// already have logic to deal with implicit lexical
$_. The pad offset of $_ is stored in the match op itself. We can
take advantage of that and extend it to lexical variables in general.
That way we have fewer ops to execute, as $lex =~ // no longer calls
pp_padsv. It also allows lexical variables’ names to be mentioned in
uninitialized warnings for y///.
|
| |
|
|
|
| |
The offset in op_targ is sufficient. The next commit will take advan-
tage of this.
|
| |
|
|
|
| |
A recent commit gave some warnings about format types,
and assignments without extra parens within an if condition.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Factor out all the things that were common for the different test
cases (which was everything except the filename). And use made-up
names that indicate what's being tested rather than special system
filenames commonly found on Unix systems. Otherwise, if, for
example, a test for "'init.d' is a directory" fails, you'd be
wondering whether something is wrong with your system rather than
looking for problems in File::Spec, which is what we're testing.
|
| |
|
|
|
|
|
| |
We had very carefully created a lexical variable to hold a default
result when the filename was undefined. Then we forgot to use it.
Now we use it.
|
| |
|
|
|
|
|
|
| |
The docs say that the filename portion of base is ignored, but they
don't specify what happens when base is a single component without
directory syntax, leaving ambiguous whether it's a file or a Unix-
style directory spec. Let's default to the latter for greatest
consistency with what happens elsewhere.
|
| |
|
|
|
|
|
|
| |
For a long time we've punted to the Unix method if either path or
base has a forward slash in it. But that really only works if
*both* are not native specs. So check for that by making sure we
don't have unescaped left bracket (square or angle) or colon in
either parameter before handing off to File::Spec::Unix::abs2rel.
|
| |
|
|
|
|
| |
We need to make the path and base parameters absolute before
splitting them apart and comparing their pieces. Since rel2abs
will do its own canonpath, we don't need to do that anymore here.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Instead of detaching both the rhs and lhs and then freeing the assign-
ment and the lhs, just detach the rhs and free the assignment. This
results in smaller machine code.
|
| |
|
|
|
| |
When this is called, the op is not part of a larger tree yet, so its
sibling is always NULL.
|
| |
|
|
|
|
|
|
|
|
|
| |
It doesn’t matter whether things in this table are ordered by opcode,
because the indices into it are stored in PL_op_private_bitdef_ix.
If we have multiple ops with exactly the same private flags, we don’t
need multiple entries in PL_op_private_bitdefs.
One practical advantage is that patches are less likely to conflict,
which will make rebasing easier. (I hope.)
|
| |\
| |
| |
| |
| |
| |
| |
| |
| | |
The OA_DANGEROUS op type flag indicates that an op might return a
value referenced elsewhere, so list assignment should make tempor-
ary copies.
Some ops had this flag needlessly. Some lacked it erroneously,
resulting in bugs.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
OA_DANGEROUS indicates that temporary copies may need to be made in
list assignment, to handle things like:
($a, $b) = ($b, $a);
In other words, an op type is flagged with OA_DANGEROUS if its return
values could occur elsewhere on the stack.
values and each can both return scalars that are referenced elsewhere,
causing list assignment to behave erratically if temporary copies
are not made.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
OA_DANGEROUS indicates that temporary copies may need to be made in
list assignment, to handle things like:
($a, $b) = ($b, $a);
In other words, an op type is flagged with OA_DANGEROUS if its return
values could occur elsewhere on the stack.
kill only ever returns a target unused elsewhere, so it does not
necessitate temp copies in list assignment.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
OA_DANGEROUS indicates that temporary copies may need to be made in
list assignment, to handle things like:
($a, $b) = ($b, $a);
In other words, an op type is flagged with OA_DANGEROUS if its return
values could occur elsewhere on the stack.
When exec fails, it only ever returns a target unused elsewhere, so it
does not necessitate temp copies in list assignment.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
OA_DANGEROUS indicates that temporary copies may need to be made in
list assignment, to handle things like:
($a, $b) = ($b, $a);
In other words, an op type is flagged with OA_DANGEROUS if its return
values could occur elsewhere on the stack.
‘write’ only ever returns a read-only true or false, so temp copies
are not necessary for its sake.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
OA_DANGEROUS indicates that temporary copies may need to be made in
list assignment, to handle things like:
($a, $b) = ($b, $a);
In other words, an op type is flagged with OA_DANGEROUS if its return
values could occur elsewhere on the stack.
tied returns the same scalar that the tied variables uses to hold a
reference to the object (so weaken(tied(...)) works). tie uses the
very scalar that TIESCALAR (or TIEWHATEVER) returns and attaches it to
the tied variable by magic. That returned scalar could be referenced
elsewhere. That means
($a, $b) = ($c, tied $d)
could have common vars on either side, if the tie constructor for $d
happened to return $a or $b. (Normally it would have to be an XSUB or
an lvalue sub for its return value not to have been copied.)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
OA_DANGEROUS indicates that temporary copies may need to be made in
list assignment, to handle things like:
($a, $b) = ($b, $a);
In other words, an op type is flagged with OA_DANGEROUS if its return
values could occur elsewhere on the stack.
exit usually doesn’t return. When it fails, it returns a read-only
undef, so we don’t need temp copies for its sake.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
OA_DANGEROUS indicates that temporary copies may need to be made in
list assignment, to handle things like:
($a, $b) = ($b, $a);
In other words, an op type is flagged with OA_DANGEROUS if its return
values could occur elsewhere on the stack.
These operators never return, so they shouldn’t necessitate
temp copies.
(This could probably apply to dump, too, but I don’t fully under-
stand dump.)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
OA_DANGEROUS indicates that temporary copies may need to be made in
list assignment, to handle things like:
($a, $b) = ($b, $a);
In other words, an op type is flagged with OA_DANGEROUS if its return
values could occur elsewhere on the stack.
die never returns, so it shouldn’t necessitate temp copies.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
OA_DANGEROUS indicates that temporary copies may need to be made in
list assignment, to handle things like:
($a, $b) = ($b, $a);
In other words, an op type is flagged with OA_DANGEROUS if its return
values could occur elsewhere on the stack.
?: always returns one of its arguments. Since aassign_common_vars,
which does the danger check, also checks the kids of the cond_expr op,
it is not necessary for cond_expr to be flagged this way.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
OA_DANGEROUS indicates that temporary copies may need to be made in
list assignment, to handle things like:
($a, $b) = ($b, $a);
In other words, an op type is flagged with OA_DANGEROUS if its return
values could occur elsewhere on the stack.
grep returns its arguments, while map returns the results of its first
expression. Since aassign_common_vars, which does the danger check,
will also check the kids of the mapstart/grepstart ops, it is not nec-
essary for grep and map themselves to be flagged this way.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OA_DANGEROUS indicates that temporary copies may need to be made in
list assignment, to handle things like:
($a, $b) = ($b, $a);
In other words, an op type is flagged with OA_DANGEROUS if its return
values could occur elsewhere on the stack.
pp_sort returns its arguments. aassign_common_vars will check its kid
ops for danger as well, so it’s not necessary for sort itself to be
flagged this way. This will allow cases like ($a,$b) = sort($c,$d) to
forego the temp copy.
|
| |
|
|
|
|
| |
Commit d5ec29879 in 2006 started storing all the hints in COPs. Some
VMS-specific hints have nonetheless still been copied from PL_hints to
cop->op_private, though that is no longer necessary.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OA_DANGEROUS indicates that temporary copies may need to be made in
list assignment, to handle things like:
($a, $b) = ($b, $a);
In other words, an op type is flagged with OA_DANGEROUS if its return
values could occur elsewhere on the stack.
While pp_postinc may return a lexical scalar, that only happens when
the OPpTARGET_MY optimisation is happening; and aassign_common_vars in
op.c checks specifically for that.
Otherwise, it only returns a mortal or target, so it is not
OA_DANGEROUS.
|
| |
|
|
|
| |
I don’t know why this was not done to begin with. The previous two
commits fixed the only outstanding problems I am aware of.
|
| |
|
|
|
|
| |
Its target may be a lexical scalar (under ‘use integer’ currently, and
soon even outside of ‘use integer’). The assignment in $lex = $foo++
currently gets optimised away and ++ writes directly to $lex.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Operators generally have targets, that is, scalars in the pad that are
used to return values. The same scalar is used again and again for
efficiency.
If the value assigned to a target is a reference, that can be bad,
because the referent will last longer than expected, even forever.
$ref++ used to have this problem (bug #9466).
So commit v5.13.4-148-g7dcb9b9 fixed it by returning a new mortal if
the return value was a reference.
However, under ‘use integer’, the OPpTARGET_MY optimisation is per-
mitted on postdec and postinc (why only under ‘use integer’ I don’t
know). Under that optimisation, $lexicalvariable = <some op> has the
assignment optimised away and the lexical variable becomes the operat-
or’s target.
If we skip assigning to the target and it is a lexical variable, then
the assignment never happens:
$ perl5.14.4 -le 'my $x=7; $_={}; $x = $_++; print $x'
HASH(0x7ff4a8806d00)
$ perl5.14.4 -Minteger -le 'my $x=7; $_={}; $x = $_++; print $x'
7
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This way a failing result doesn't carry over between subtests.
|
| | |
|
| | |
|
