| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Additional documentation related entries have not yet been added
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This used not to work:
sub foo :lvalue { keys %wallet }
foo = 37;
Now it does. It was just a matter of following the right code path in
op_lvalue when the parent op is a leavesublv instead of a sassign.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This script works in 5.6.x:
#!perl -l
sub MODIFY_SCALAR_ATTRIBUTES { return } # need these
sub MODIFY_ARRAY_ATTRIBUTES { return } # for it to
sub MODIFY_HASH_ATTRIBUTES { return } # compile
my ($x,@y,%z) : Bent = 72; # based on example from attributes.pm’s pod
print $x;
print "ok";
$ pbpaste|perl5.6.2
72
ok
(pbpaste is a Mac command that outputs the clipboard contents.)
In 5.8.0 to 5.8.8:
$ pbpaste|perl5.8.1
ok
So the assignment never happens. And with warnings:
$ pbpaste|perl5.8.1 -w
Bizarre copy of ARRAY in aassign at - line 5.
In 5.8.9 it gets slightly worse:
$ pbpaste|perl5.8.9
Bizarre copy of ARRAY in aassign at - line 5.
So warnings are not required to trigger the error. If my ($x,@y,%z)
is changed to my($x,$y), there is no error, but the assignment
doesn’t happen.
This was broken in 5.8.0 by this change:
commit 95f0a2f1ffc68ef908768ec5d39e4102afd28c1e
Author: Spider Boardman <spider@orb.nashua.nh.us>
Date: Sat Dec 8 19:09:23 2001 -0500
Re: attributes are broken
Message-Id: <200112090509.AAA02053@Orb.Nashua.NH.US>
p4raw-id: //depot/perl@13543
(Is there a ‘hereby’ missing from that subject? :-)
Oddly enough, that was the commit that put the attribute and list
assignment example in attribute.pm’s pod.
This change caused the bizarre assignment error to occur more often in
5.8.9 and 5.10.0, but I don’t think it’s actually relevant (just try-
ng to see how long I can get this commit message):
commit f17e6c41cacfbc6fe88a5ea5e01ba690dfdc7f2e
Author: Rafael Garcia-Suarez <rgarciasuarez@gmail.com>
Date: Wed Jul 5 20:00:10 2006 +0000
Fix a bug on setting OPpASSIGN_COMMON on a AASSIGN op when the left
side is made out a list declared with our(). In this case OPpLVAL_INTRO
isn't set on the left op, so we just remove that check. Add new tests.
p4raw-id: //depot/perl@28488
What’s happening is that there is an extra pushmark in the list when
attributes are present:
$ perl5.14.0 -MO=Concise -e 'my ($a,@b):foo'
o <@> leave[1 ref] vKP/REFC ->(end)
1 <0> enter ->2
2 <;> nextstate(main 39 -e:1) v:{ ->3
n <@> list vKPM/128 ->o
3 <0> pushmark vM/128 ->4
4 <0> padsv[$a:39,40] vM/LVINTRO ->5
5 <0> padav[@b:39,40] vM/LVINTRO ->6
6 <0> pushmark v ->7 <------- right here
e <1> entersub[t3] vKS*/NOMOD,TARG ->f
7 <0> pushmark s ->8
8 <$> const[PV "attributes"] sM ->9
9 <$> const[PV "main"] sM ->a
b <1> srefgen sKM/1 ->c
- <1> ex-list lKRM ->b
a <0> padsv[$a:39,40] sRM ->b
c <$> const[PV "foo"] sM ->d
d <$> method_named[PV "import"] ->e
m <1> entersub[t4] vKS*/NOMOD,TARG ->n
f <0> pushmark s ->g
g <$> const[PV "attributes"] sM ->h
h <$> const[PV "main"] sM ->i
j <1> srefgen sKM/1 ->k
- <1> ex-list lKRM ->j
i <0> padsv[@b:39,40] sRM ->j
k <$> const[PV "foo"] sM ->l
l <$> method_named[PV "import"] ->m
-e syntax OK
That leaves an extra mark that confuses pp_aassign, which doesn’t know
what it’s supposed to be reading and what it’s supposed to be assign-
ing to (hence the bizarre copy).
The pushmark is the result of the concatenation of two lists, the sec-
ond one beginning with a pushmark (as listops do by default). The con-
catenation occurs in Perl_my_attrs, at this spot (in the ‘else’):
if (rops) {
if (maybe_scalar && o->op_type == OP_PADSV) {
o = scalar(op_append_list(OP_LIST, rops, o));
o->op_private |= OPpLVAL_INTRO;
}
else
o = op_append_list(OP_LIST, o, rops);
}
So this commit make that ‘else’ clause check for a pushmark and oblit-
erate it if present, before concatenating the lists.
|
|\ |
|
| | |
|
|/ |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Since I just updated 5.14.1’s perldelta, it made sense to go ahead and
do this. For a list of the commits that are dealt with here, log into
cherrymaint and look for anything recent marked ‘Cherry-picked’.
I did not bother including the Ubuntu library path and Darwin test
fixes. I don’t think they are worth mentioning, but others may disa-
gree... (‘may’ in both senses).
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
process.
The outcome of kill on a pseudo-process in Windows is unpredictable
and it should not be used except under dire circumstances.
The process which implements the pseudo-processes can be blocked
and the Perl interpreter hangs.
|
|
|
|
|
|
|
|
| |
If something has a portability issue, we should mention it in the main
place people will read about the thing with the issue. For Perl
built-ins, that's perlfunc. We don't have to explain the issue, but we
should at the very least tell people where to find an explanation of
the issue.
|
|
|
|
| |
Summary paragraph received by email from Dave Mitchell.
|
|
|
|
|
|
|
|
|
|
| |
I looked through all my commits, and came up with this text for all the
ones I think could possibly be desired to put into the perldelta. All
other commits I've made for 5.15 so far, can be ignored IMO as far as
the delta is concerned. I'm not so sure about even the ones I've
done here. Feel free to omit them. The wording for the edge case is
convoluted; but it's hard for me to describe the complicated
circumstances when the bug appeared.
|
|
|
|
| |
both 'to child' and 'from child' were listed as "|-"
|
|
|
|
|
|
|
| |
[perl #88014] demonstrated that the docs for string eval misleadingly
implied that the code wasn't executed within new new block scope,
leading to false expectations that $1 etc would retain their values
outside the eval.
|
| |
|
|
|
|
|
| |
This was originally reported at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=485467:
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
| |
This reverts commit c72c0c0bdd3dbc2b529b28a4f324a1cc149a6453
at Jesse’s request.
|
|
|
|
|
| |
This reverts commit 6b8305409e650748b2e6fb75634200370b69238b
at Jesse’s request.
|
| |
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
This fixes some verbatim text exceeding an 80 column window by shortening
two =over amounts.
|
|
|
|
|
|
| |
This fixes some issues with the pod wrapping verbatim in 80 column
windows by indenting less, and not having the comments so far to the
right
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While trying to understand a bug report at
http://www.perlmonks.org/?node_id=906466
I realized that the documentation for $! was not crystal clear. For example
If used numerically, yields the current value of the
C C<errno> variable, or in other words,
if a system or library call fails, it sets this variable.
That's not "in other words", these are totally different
concepts. And it isn't clear whether this variable refers to
errno or $! (I assumed the latter, and was wrong, as Devel::Peek
demonstrated). And $! cannot be undef, as asserted (later),
because errno always contains a value, however irrelevant.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In pod/perldata it is described that the DATA filehandle starts
reading after the __DATA__ token. In reality, it starts reading on the
line following the __DATA__ token.
Example:
print while <DATA>; __DATA__ foo
bar
This prints "bar", not "foo\nbar".
The attached patch fixes the documentation in pod/perldata.pod.
|
| |
|
| |
|
| |
|
|
|
|
| |
1c2e8ccaafb0b2b1 fixed a typo in a comment in the XS code.
|
|
|
|
| |
1b95d04f713d9c56 changed HvKEYS() to HvUSEDKEYS() in the XS code.
|
|
|
|
|
|
|
|
|
|
| |
Previous perldeltas have been inconsistent with each other as to whether to
use L<> to C<> (but internally consistent). perldelta5140.pod uses L<>, which
is more useful, as it provides a direct link to fuller documentation at the
point where the reader is likely to want to follow it.
Switch the two existing entries from C<> to L<>, and update the perldelta
template to suggest L<>.
|
| |
|
| |
|
| |
|
| |
|