| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[DELTA]
2.112621 2011-09-19 12:15:16 America/New_York
[BUGFIX]
- Spell BACKEND environment variables correctly this time
[noticed by Stevan Little]
2.112620 2011-09-18 20:56:06 America/New_York
[BUGFIX]
- Protect tests against PERL_(YAML|JSON)_BACKEND settings that could
cause tests to fail. (RT #69979)
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
[DELTA]
2.112600 2011-09-17 12:21:09 America/New_York
[DOCUMENTATION]
- Fixed spelling error in CPAN::Meta::Spec (RT #71036) [Gregor Hermann]
|
|
|
|
|
|
|
|
|
| |
This patch makes perldoc with a URL use a somewhat reasonable name
based on the basename of the URL, instead of displaying PALLEGCSYO or
BJ1KKH1675 in the pod header (based on the tmp file name).
It treats all URLs the same (changing perldoc.pod to PERLDOC), instead
of treating .pm’s specially. Maybe this could be improved later.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Here is some suspicious code in Perl_my_lstat_flags:
if (SvROK(sv) && isGV_with_GP(SvRV(sv)) && ckWARN(WARN_IO)) {
Perl_warner(aTHX_ packWARN(WARN_IO), "Use of -l on filehandle %s",
GvENAME((const GV *)SvRV(sv)));
return (PL_laststatval = -1);
}
The behaviour differs depending on whether warnings are enabled.
That -1 turns into undef in pp_ftlink. So we get an undef return
value with warnings on, but a file test on a file name otherwise.
In 5.6.2, -l $foo always treated $foo as a file name.
In 5.8+, if it is a reference (ignoring magic) and the reference
points to a typeglob (ignoring magic) and io warnings are on, it warns
and returns undef.
So the only time that undef return is reached is when a warning has
been emitted, so it’s code that will likely be corrected before it
goes into production. Hence I think it unlikely that anyone could be
relying on the behaviour of -l \*foo (under warnings).
So this commit restores the 5.6 behaviour for that case.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Perl 5.10.0 introduced stacked filetest operators,
-x -r $foo
being equivalent to
-r $foo && -x _
That does not work with -l. It was these suspicious lines in
Perl_my_lstat_flags that drew my attention to it:
> else if (PL_laststype != OP_LSTAT
> && (PL_op->op_private & OPpFT_STACKED) && ckWARN(WARN_IO))
> Perl_croak(aTHX_ no_prev_lstat);
That croak only happens when warnings are on. Warnings are just
supposed to be warnings, unless the ‘user’ explicitly requests
fatal warnings.
$ perl -le 'print "foo", -l -e "miniperl"'
foo
$ perl -lwe 'print "foo", -l -e "miniperl"'
The stat preceding -l _ wasn't an lstat at -e line 1.
That it doesn’t die in the first example is a bug.
In fact, it’s using the return value of -e as a file name:
$ ln -s miniperl 1
$ ./miniperl -le 'print -l -e "miniperl"'
1
And, with warnings on, if the preceding stat *was* an lstat, it
falls back to the pre-stacked behaviour, just as it does when warn-
ings are off.
It’s meant to be equivalent to -e "miniperl" && -l _ (which is why the
error message above says ‘The stat preceding -l _’).
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This is to address ticket #94252.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See <https://rt.cpan.org/Ticket/Display.html?id=66474>. Also, this
came up in <https://rt.perl.org/rt3/Ticket/Display.html?id=92728>.
The <> operator, when reading from the magic ARGV handle, automatic-
ally opens the next file. Layers set by the lexical open pragma are
applied, if they are in scope at the point where <> is used.
This works almost all the time, because the common convention is:
use open ":utf8";
while(<>) {
...
}
IO::Handle’s getline and getlines methods are Perl subroutines
that call <> themselves. But that happens within the scope of
IO/Handle.pm, so the caller’s I/O layer settings are ignored. That
means that these two expressions are not equivalent within in a
‘use open’ scope:
<>
*ARGV->getline
The latter will open the next file with no layers applied.
This commit solves that by putting PL_check hooks in place in
IO::Handle before compiling the getline and getlines subroutines.
Those hooks cause every state op (nextstate, or dbstate under the
debugger) to have a custom pp function that saves the previous value
of PL_curcop, calls the default pp function, and then restores
PL_curcop.
That means that getline and getlines run with the caller’s compile-
time hints. Another way to see it is that getline and getlines’s own
lexical hints are never activated.
(A state op carries all the lexical pragmata. Every statement
has one. When any op executes, it’s ‘pp’ function is called.
pp_nextstate and pp_dbstate both set PL_curcop to the op itself. Any
code that checks hints looks at PL_curcop, which contains the current
run-time hints.)
|
| |
|
|
|
|
| |
introduced by 7168b2511bddd4967be30033b32ce8b1b6500f6d
|
| |
|
|
|
|
|
|
| |
A lot of this is fixing the incorrect meme of "an object is a blessed
reference", but this change also corrects a number of typos, adds clarifying
bits of text, etc.
|
|
|
|
|
| |
Mostly this consists of removing the incorrect meme that an object is a
blessed reference.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since goto &foo is supposed to replace the current sub call, as though
foo had been called instead, logically foo should see the same lexical
hints that would have been seen if it had been called to begin with.
Regular Perl subs begin with nextstate ops, so they have their own
lexical scopes, but CORE:: subs see the caller’s PL_curcop. They lack
a nextstate precisely so that they run in the caller’s scope, just as
though a built-in function had been called.
For Perl subs (as opposed to XSUBs), goto-&sub was not reset-
ting PL_curcop to the caller’s value, but leaving as it was, so
goto &CORE::sub would cause the CORE sub to run with the lexical hints
of the subroutine in replaced, instead of that sub’s caller.
This was never a problem until CORE subs came along, as they look like
Perl subs to the internals (they have an op tree and are flagged as
such), but comprise a sequence of ops that can never result from com-
piling Perl source code.
The simple one-line fix is to set PL_curcop in pp_goto for Perl subs
as well as XSUBs. (For XSUBs it is implied by POPBLOCK.)
|
|
|
|
| |
These ops considered typeglobs read-only, even if they weren’t.
|
|
|
|
|
|
|
|
|
| |
On some systems, csh croaks if the LS_COLORS envvar contains something
it considers invalid.
The easiest and least intrusive fix for now is to localize %ENV before
running csh, though eventually it might be nice to use File::Glob in
miniperl, either by linking it statically or by inlining it.
|
|
|
|
|
|
|
|
|
|
|
| |
[DELTA]
2.112580 2011-09-15 10:53:59 America/New_York
[BUGFIX]
- Use UTF-8 mode for internal structure cloning to avoid bugs
in Perl <= 5.8.6 (RT #70936) [Dagfinn Ilmari Mannsåker]
|
|
|
|
|
|
|
|
|
| |
[DELTA]
Changes for 0.9111 Fri Sep 16 10:15:06 2011
================================================
* Enhance CPANPLUS::Dist::MM Makefile/Makefile.PL
age checking code to resolve some issues.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
$ perl -MScalar::Util=weaken -le 'DESTROY{return if$_++;weaken$_[0]}$x=bless[]'
DESTROY created new reference to dead object 'main' during global destruction.
It says that because the reference count has gone down to -1 (or the
max unsigned value, whichever it is), and the error occurs when
SvREFCNT is true. So there is no new reference to the dead object;
it’s just the refcount that’s off.
This case is worse:
$ perl -MScalar::Util=weaken -le 'DESTROY{weaken$_[0];$x=$_[0]}bless[];'
Segmentation fault
$_[0]’s reference count is normally lowered manually by sv_clear, to
avoid a recursive call to sv_clear (as lowering the reference count
normally triggers that). If the variable has been weakened, then
$_[0] no longer holds a reference count. sv_clear proceeds to destroy
at, as its reference count is 1 (held by $x), causing $x to point to a
freed scalar. Not good.
Since $_[0] is read-only anyway, it should not be weakenable.
|
| |
|
|
|
|
| |
This reverts commit 6a945912f2861921b440402072b7053a1dc414a5.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|