| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
That RT ticket reported that a $ prototype puts an implicit scalar()
on its argument, and that scalar(lvalue()) causes the function to
return a temporary value. In particular:
${\scalar($_)} = 1; # ok
${\scalar f()} = 1; # no effect
(where f is an lvalue sub that returns $_).
It turns out that this does not only affect scalar(), but also
|| and &&:
${\($_ && undef)} = 3; # ok
${\(f() && undef)} = 3; # no effect
Also, that comment in pp_leavesublv about f()->meth() not being lvalue
context is wrong, as
$o->${\sub { $_[0] = "whatever" }};
assigns to $o, and
sub UNIVERSAL::undef { undef $_[0] }
allows calls like
$x->undef
to undefine $x, if it contains an object or package name.
Since copying values in rvalue context is wasteful anyway, since the
definition of rvalue context is that the value is going to be copied
(resulting in *two* copies), the easiest solution is not to copy val-
ues in rvalue context.
This ends up applying to what I call ‘reference’ context (semi-lvalue,
or potential lvalue) as well.
This works already with explicit return.
As a bonus, this also fixes bug #78680, for which there are already
to-do tests that were added before the bug was reported. See also:
http://www.nntp.perl.org/group/perl.perl5.porters/;msgid=20060118203058.GQ616@plum.flirble.org
|
| |
|
|
|
|
|
| |
test arithmetic folding, conditional folding (both true & false),
and string, lc() & uc() folds, and mixed string.int folds.
Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
|
| | |
|
| |
|
|
|
| |
including the ‘Useless assignment to a temporary’ warning
which is only triggered by these.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
As George Greer noted on p5p, --attach causes the message to be
written using MIME-attach syntax, so when perlbug sends it,
rt.perl.org detaches the file and adds it to the ticket.
While tradtional inline patches appear to survive without whitespace
mangling, attachments are more in keeping with RTs design and use.
Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
|
| |
|
|
|
|
|
|
|
| |
patch does:
perl -pi -e 's/$::opt_(\w)/$opt{$1}/g' perlbug.PL
adds my %opt decl, and in getopts.
drops no warnings 'once'
Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
|
| | |
|
| | |
|
| |
|
|
|
| |
I cannot find any information on these, but that comment
is erroneous and that sub is not doing anything.
|
| |
|
|
|
| |
This reverts commit c72c0c0bdd3dbc2b529b28a4f324a1cc149a6453
at Jesse’s request.
|
| |
|
|
|
| |
This reverts commit 6b8305409e650748b2e6fb75634200370b69238b
at Jesse’s request.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In perl 5.8.1 and earlier, sub{} would return @_ in list context. This
was fixed in 5.8.2 for regular subs, but not lvalue subs.
Before the syntactic restriction on return values was removed in
commit 145b2bb, there was a bug affecting compilation of empty subs
before any use statement:
$ perl5.14.0 -e 'sub foo :lvalue {}'
Can't modify stub in lvalue subroutine return at -e line 1, near "{}"
Execution of -e aborted due to compilation errors.
$ perl5.14.0 -le 'use sigtrap; sub foo :lvalue {} print "ok"'
ok
But I digress. :-)
Up to 5.14, lvalue subs were still returning @_, or, rather, the ele-
ments of @_ as separate scalars:
$ perl5.14.0 -Mre -le '(sub :lvalue {}->($a,$b))=(3,4); print "$a $b"'
Useless use of "re" pragma at -e line 0
3 4
(Not exactly useless, eh? The -Mre allows the sub to compile.)
This commit fixes that bug.
|
| |
|
|
| |
Lvalue subs *can* return lists
|
| |
|
|
|
|
|
|
|
| |
Support for lvalue subroutines has been stable and reliable for more
than 10 years. Despite this, they are still marked as being
experimental.
This patch removes the 'experimental' warnings from the docs, and
adjusts the description accordingly.
|
| |
|
|
|
|
|
| |
This changes the syntax of the last statement and the arguments to
‘return’ in an lvalue subroutine to be the same as that of a non-
lvalue routine. This almost finishes the work begun by commit fa1e92c.
(return still needs to enforce the same rules as leavesublv.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is perhaps not ideal, but it fixes (or allows to be fixed) seve-
ral bugs.
I was hoping that the cases that this perhaps erroneously allows
through would fall back to the warning I added in commit 8fe85e3, but,
unfortunately, in all these cases the refcount is greater than 1 when
pp_sassign is reached.
To be less vague: ‘foo() = 3’ warns if foo() returns a TEMP with no
set-magic and a refcount of 1 (meaning it will be freed shortly). But
truly temporary values returned by pure-Perl lvalue subs have a refer-
ence count of at least 2, and as many entries on the mortals stack.
I cannot distinguish between truly temporary values and those that
are but nominally temporary (marked TEMP because the refcount will go
down, but not to zero) by checking for a refcount <= 2 in pp_sassign,
because this example returns with a refcount of 2:
+sub :lvalue { return delete($_[0]), $x }->($x) = 3; # returns a TEMP
There’s no logical reason why that shouldn’t work, if this does:
+sub :lvalue { return foo(), $x }->($x) = 3; # not TEMP
as they are conceptually identical.
The advantages to this change:
• The delete example above will work.
• It allows XS lvalue subs that return TEMPs to work in the debugger
[perl #71172], restoring the bug fix that b724cc1 implemented but
c73030b reverted.
• It makes these three cases identical, as they should be. Note that
only two of them return TEMPs:
+sub :lvalue { return shift }->($x) = 3;
+sub :lvalue { \@_; return shift }->($x) = 3; # returns a TEMP
+sub :lvalue { return delete $_[0] }->($x) = 3; # returns a TEMP
So I think the advantages outweigh the disadvantages.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit b724cc14b25929aee44eee20bd26102cceb520b6.
Lvalue subroutines are more of a mess than I realised when I made
that commit.
I just tried removing the syntactical restriction on what the last
statement or the argument to return can be in an lvalue sub. It opened
a whole can of worms.
PADTMPs are bizarre creatures that have somewhat erratic behaviour.
Since assigning to a PADTMP is almost always a mistake (since the
value will definitely be discarded), those *should* be disallowed,
when the sub is called in lvalue context. That also avoids propagating
a whole load of bugs when referencing PADTMPs, aliasing to them, etc.
Read-only scalars end up triggering a ‘Modification of a read-only
value attempted’ message without the restrictions in pp_leavesublv,
but the message the latter was providing (which this revert restores)
is clearer (‘Can't return a readonly value from lvalue subroutine’).
Speaking of lvalue context, there are three types of context with
regard to lvalue-ness (orthogonal to the usual void/scalar/list
contexts):
• rvalue context ($x = func())
• lvalue context (func() = $x)
• semi-lvalue context (\func())
Each is handle by a separate code path in pp_leavesublv:
• rvalue context - any value can be returned; it’s copied (waste-
ful, perhaps?)
• semi-lvalue context - any value can be returned; it’s not copied
• lvalue context - stringent rules about what can and cannot be
returned (which this revert restores)
So it is perfectly fine to restrict what can be returned from an
lvalue sub *in true lvalue context*, without affected rvalue use.
Now, regarding TEMPs, although this commit restores the restriction on
returning TEMPs, a forthcoming commit will relax that restriction once
more, since it causes bugs.
|
| |
|
|
|
|
| |
When this test was written, t the new 5.14 regex modifiers were
not usable in suffix notation. That changed before 5.14 shipped,
but the test did not.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
In perlhack,
% perlbug -s "[PATCH] $(git log -1 --format=%s HEAD)" -f 0001-*.patch
is incomplete; --format=%s needs a proper value.
Use --oneline instead, as it also --abbrev(iates) sha1
$ git log --oneline -1
c8dfc96 regexp.h: repair linux perf compilation
Note that HEAD is optional, but just as clear as <branch-name>.
|
| |
|
|
|
|
|
|
|
| |
The section of documentation in perlguts for the sv_setref_* functions
was ambiguous: it wasn't clear whether each paragraph was referring to
the function above or below it. Fix this by prepending lots of "The
following function...".
Also fix a couple of functions signatures.
|
| |
|
|
| |
Commit f71f472 missed list assignment. :-(
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This commit removes the restriction on returning temps and read-only
scalars from lvalue subs that occurs when the sub returns implicitly
(with no ‘return’ statement; ‘return’ has never had that restriction).
It does not actually help pure-Perl lvalue subs much yet, as op.c
still enforces lvalue syntax on the last statement.
But this should fix bug #71172, allowing XS lvalue subs to work under
the debugger.
|
| | |
|
| |
|
|
| |
This is something that fa1e92c missed.
|
| |
|
|
| |
5.14.1 is now using the number 1.04.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the first step in downgrading a fatal error (Can't return a
temporary from lvalue subroutine) to a warning. Currently only XS
lvalue routines that return TEMPs and pure-Perl lvalue routines that
use explicit return (which don’t quite work properly yet anyway,
despite commit fa1e92c) are affected by this.
This is implemented in pp_sassign and pp_aassign, rather than
pp_leavesublv, so it will affect explicit returns and so it will
be skipped for overloaded ‘.=’, etc.
Thanks to Craig DeForest for suggesting how to do this.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In @INC filters (subs returned by subs in @INC), $_ is localised to a
variable to which the next line of source code is to be assigned. The
function in pp_ctl.c that calls it (S_run_user_filter) has a pointer
to that variable.
Up till now, it was not setting the refcount or localising
$_ properly.
‘undef *_’ inside the sub would destroy the only refcount it
had, leaving a freed sv for toke.c to parse (which would crash,
of course).
In some cases, S_run_user_filter has to created a new variable. In
those cases, it was setting $_ to a mortal variable with the TEMP
flag, but with a refcount of 1, which would result in ‘Attempt to free
unreferenced scalar’ warnings if the $_ were freed by the subroutine.
This commit changes S_run_user_filter to use SAVEGENERICSV, rather
than SAVE_DEFSV, to localise $_, since the former lowers the refcount
on scope exit, while the latter does not. So now I have also made it
increase the refcount after assigning to the now-properly-localised $_
(DEFSV). I also turned off the TEMP flag, to avoid weird side effects
(which were what led me to this bug to begin with).
|
| |
|
|
|
|
| |
I reverted the first version of this patch because I put the if()
statement before a declaration. I did a revert, rather than a correc-
tion, to make back-porting easier.
|
| |
|
|
| |
This reverts commit 40f11004fb3b5fa1cd207a20090df837d721b736.
|
| |
|
|
|
|
|
| |
Properties with no elements are defined in terms of the complement
of the property which matches all of Unicode: \p{Any}. But it
currently is defined in terms of IsAny, which is user-overridable;
Just drop the 'Is'
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
utf8::decode was not respecting copy-on-write, but simply modify-
ing the PV (the scalar’s string buffer) in place, causing problems
with hashes:
my $name = "\x{c3}\x{b3}";
my ($k1) = keys %{ { $name=>undef } };
my $k2 = $name;
utf8::decode($k1);
utf8::decode($k2);
print "k1 eq k2 = '", $k1 eq $k2, "'\n";
my $h = { $k1 => 1, $k2 => 2 };
print "{k1} '", $h->{$k1}, "'\n";
print "{k2} '", $h->{$k2}, "'\n";
This example (from the RT ticket) shows that there were two hash ele-
ments with the same key.
As of this commit, the hash only has one element.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Currently bits 256 and 512 of the floating point len arg are used to
flag extra things. Since we have 32-bit args now, change these bits
to higher ones so there's no such arbitrary restriction.
Also, define two symbolic constants rather than hard-coding in the bit
values.
|
| |
|
|
|
|
|
|
| |
Back in 2003, the format bytecode was changed to allow 32-bit offsets,
but all the stored offsets were still being cast to U16. So for example
only the first char of a 65537 char literal would be output.
This commit removes all the U16 casts.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We initially grow PL_formtarget by the largest amount a formline can
append (since formats are fixed width). The only thing that can exceed
that is @*; but also, if PL_formtarget gets upgraded to utf8, then some of
the extra buffer we allocated can get eaten up by the upgrade.
Codify this so we only grow when necessary, but always enough.
Prior to this commit, we were growing FF_ITEM/FF_LITERAL too much, and
FF_LINEGLOB too little (the latter being my mistake from a few commits
ago).
Also rename 'fudge' to 'linemax', to give a better idea what it's for.
|
| |
|
|
|
|
|
|
| |
linemark is a pointer to the current start of the line. This allows
things like ~ to delete back to the start of the line.
Convert it into an offset, so that it isn't invalidated if PL_formtarget
is reallocated. Also recalculate it if PL_formtarget is upgraded to utf8.
|
| |
|
|
|
|
| |
Now that we've got the two chunks of append code similar enough to each
other, make FF_ITEM just goto into the append part of the FF_LINEGLOB
code.
|
| |
|
|
|
|
| |
Now that we've got the two chunks of append code similar enough to each
other, make FF_LITERAL just goto into the append part of the FF_LINEGLOB
code.
|
| |
|
|
|
|
|
|
|
|
|
| |
In various places, PL_formtarget is grown by fudge bytes.
But fudge is already equal to the whole width of the format line,
and PL_formtarget is pre-grown by fudge at the start, so normally
there's no need to extend it further. So don't.
Instead, only grow it by the amount needed (which will ormally be nothing)
as a safety measure.
Also add an assert at the end to check that we haven't overrun the buffer.
|
| |
|
|
|
| |
We don't care whether PL_formtarget has a trailling \0 until we return;
so remove the bits where we add one in between.
|
| |
|
|
|
|
|
| |
The code currently does SvCUR_set(PL_formtarget,...) in three out of four
of the condition branches. Since it's harmless to do it also for the
fourth, remove the three individual SvCUR_set()s and replace with a single
unconditional one.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This var is used to enable padding or truncating of output items.
FF_LINESNGL/FF_LINEGLOB do their own version of this, so there's
no need to set it there.
Or to put it another way, we don't expect a FF_LINESNGL or FF_LINEGLOB op
to be followed immediately by FF_SPACE, FF_HALFSPACE, FF_ITEM nor FF_MORE.
Not calculating it makes the code simpler and eases the path to merging
the appending code.
|
| |
|
|
|
| |
This is in preparation for merging with the FF_LINEGLOB code.
Should be no change in functionality.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Two of the three branches that upgrade PL_formtarget to utf8 (FF_LITERAL,
FF_ITEM) do get magic while doing so, while the third (FF_LINEGLOB)
doesn't. I think the first two were just co-incidental
(they started out as simple sv_utf8_upgrade() calls added by
1bd51a4ce2ce8, and probably no consideration was given as to whether to
use the _nomg variant instead).
Make the first two no longer call magic, to be consistent with
FF_LINEGLOB.
|
| |
|
|
| |
The second block is shortly going to be used by others too
|
