| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
The GCC_DIAG_IGNORE(-Wpedantic) stuff added by me to
STATIC_ASSERT_GLOBAL() by ac892e4a230de5b was causing some smoke failures.
I don't yet understand why.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
The initialisers for PL_inf and PL_nan disabled -Wc++-compat warnings for
some ifdef branches but not others. Expand the scope of the
GCC_DIAG_IGNORE() to all cases.
|
| |
|
|
|
|
| |
This horrible thing broke encapsulation and was as buggy as a very buggy
thing. It's been officially deprecated since 5.20.0 and now it can finally
die die die!!!!
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This series of commits attempts to reduce duplication and partially unify
the code that handles subroutine exit, in places like pp_leavesub,
pp_return etc. In particular, pp_return has been heavily modified so that
it is now only responsible for doing any extra work required above and
beyond that done by pp_leavesub et al (popping contexts and removing junk
left on the stack). It now tail calls pp_leavesub / pp_leaveeval/ etc to
do the remaining heavy lifting. This reduces the code size of pp_return to
about a quarter of what it was previously, and ensures that exactly the
same processes happen regardless of whether an explicit return is is done
or not.
It also fixes using return in list context in a MULTICALL, e.g.
use List::Util qw(pairmap);
@a = pairmap { for (1,2) { return (3,4)} } qw(a b);
formerly returned (1,2,3,4) and now returns (3,4).
It also simplifies S_sortcv() et al which are responsible for calling
a sort sub.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The switch statement was fairly pointless, as it was just a bunch of
case G_VOID:
return G_VOID;
so replace the switch with a simple "croak if 0, otherwise return the
value".
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Change:
if (cxix < 0) {
A; return;
}
if (cxix < cxstack_ix)
B;
to
if (cxix < cxstack_ix) {
if (cxix < 0) {
A; return;
}
B;
}
This is functionally the same, since cxstack_ix is always positive at
this point, and makes for a quicker code path (one less test and branch)
in the reasonably common case of a return from a sub which doesn't
have any extra nested contexts to pop.
|
| | |
| |
| |
| |
| | |
Re-indent a code block that got stranded after the previous commit.
Whitespace-only change.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When 'return'ing from a format, rather than handling it ourselves, fall
through to pp_leavewrite(). pp_return() is now only responsible for
popping any extra contexts and junk from the stack.
With this commit, *all* types of return are now handled by tail-calling
the appropriate pp_leaveFOO() function, so this commit also cuts out big
chunks of dead code.
Note that the behaviour on using 'return' in a format is completely
undocumented, and almost completely untested. In fact there is only a
single format in the test suite that does a return, and the tests which
use that are mainly there to ensure that extra stuff on the stack doesn't
leak into the value(s) returned by write().
In particular, its not clear whether a return half-way through a format
should cause the lines processed so far to be output, or to be discarded;
currently it discards. Also, its not clear what (if anything) should be
done with any args to the 'return' call. Currently they're just discarded.
Also, the format in the test suite which does a return only does a
'return;', not a 'return x,y,z'. So that's still untested.
So I decided to keep the current behaviour of return in format as close
as possible rather than trying to change of fix anything.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When 'return'ing from an eval STRING, rather than handling it
ourselves, fall through to pp_leaveeval(). pp_return() is now only
responsible for popping any extra contexts and junk from the stack.
This helps avoid two different blocks of code doing roughly the same
thing.
The functional changes caused by this commit signify the divergence over
time between pp_leaveeval and the try-ish parts of pp_return. After this
commit, a return will:
* now do an PERL_ASYNC_CHECK();
* be smarter about not unnecessarily creating mortal copies
of returned args;
* restore PL_curpm *before* the LEAVE() rather than after.
The first two are probably good things; I'm not sure about the latter; it
may well be a regression, but nothing tests for it. At least it's
consistent now.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
In pp_leaveval, the CvDEPTH of the eval is set to 0. This doesn't
seem to be actually necessary (no tests fail if its removed),
but for consistency, add the same step to pp_return, which currently
doesn't do this. This is so that shortly we can make pp_return tail call
pp_leaveval.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In pp_leaveeval the test to die on require not returning a true value
is done late, after the return args have been processed, while in
pp_return it is checked *before* the args are processed. Move the test in
pp_return to after the args to make it more like pp_leaveeval. This is a
preparatory step in making pp_return eventually tail call pp_leaveeval.
It probably doesn't make any difference whether it's done early or late
(although arguably dying early is infinitesimally more efficient); but
since pp_leaveeval is going to be overwhelmingly a more common way of
returning from a require than pp_return, its seems prudent to to not mess
with the most widely used code path.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In order shortly to allow pp_return to tail call pp_leaveval,
make pp_leaveval use the EVAL_KEEPERR flag bit of PL_in_eval
to decide whether to call CLEAR_ERRSV() rather than testing the
OPf_SPECIAL flag bit on the OP_LEAVEEVAL op (since we may no longer be
that op).
The two are equivalent (I checked this by running test test suite with
an assert that they were the same).
Note that pp_return already uses the EVAL_KEEPERR flag test, so this
commit makes the pp_return and pp_leavesub code blocks more similar.
I've also added some more tests, as I initially got the logic of this
wrong, and no core tests failed - only cpan/ ones. In particular, no core
tests checked whether eval-string actually cleared $@ on success!
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There's a loop which tests eval_pv, eval_sv, call_sv with various
types of argument. Currently the argument is determined by an integer
in a loop (0..3) with various values derived on an ad-hoc basis
from that index. Instead put all the data into an array of arrays
and iterate over that instead.
Similarly for the function names (eval_pv et al), loop over the names
rather than over 0..2.
This should make no functional change to what is tested, but makes the
test code clearer and more expandable.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When 'return'ing from an eval { BLOCK }, rather than handling it
ourselves, fall through to pp_leavetry(). pp_return() is now only
responsible for popping any extra contexts and junk from the stack.
This helps avoid two different blocks of code doing roughly the same
thing.
The functional changes caused by this commit signify the divergence over
time between pp_leavetry and the try-ish parts of pp_return. After this
commit, a return will:
* now do an PERL_ASYNC_CHECK();
* be smarter about not unnecessarily creating mortal copies
of returned args;
* restore PL_curpm *before* the LEAVE() rather than after.
The first two are probably good things; I'm not sure about the latter; it
may well be a regression, but nothing tests for it. At least it's
consistent now.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Currently in something like
for (1,2) { return 3,4 }
the user of MULTICALL will see 1,2,3,4 returned, because in pp_return,
MULTICALL is handled as a special case, and that special-case code doesn't
handle list context.
A simple fix is just to remove the special handling in pp_return.
Allow a MULTICALL return to pass through the normal pp_return stack
manging code, then tail call pp_leavesub or pp_leavesublv as approriate.
Both those subs do an immeidate 'return 0' if CxMULTICALL().
As well as fixing list context MULTICALL, it removes one extra condition
in the path of a normal return.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
After the previous commit, pp_leavesublv was just an empty wrapper
around S_return_lvalues() (which is also called from pp_return).
So just rename S_return_lvalues to pp_leavesublv, and make pp_return
call pp_leavesublv directly.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Currently pp_leavesublv has a check at the top:
if (CxMULTICALL(&cxstack[cxstack_ix]))
return 0;
Move this instead into S_return_lvalues(), which pp_leavesublv immediately
calls. This has no effect on the pp_leavesublv code path, and also
has no effect on the pp_return code path, because although pp_return
calls S_return_lvalues, it doesn't in the case of MULTICALL, which it has
already checked for earlier.
So it shouldn't change anything functionally.
This will allow us to eliminate S_return_lvalues in the next commit.
|
| | |
| |
| |
| | |
Just a whitespace change.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
S_return_lvalues() was written to handle both pp_leavesublv and pp_return;
in the latter case there could be junk on the stack that needs skipping;
e.g.
for (1,2) { return 3,4 }
leaves 1,2,3,4 on the stack, and in list context the 3,4 needs shifting
down two places. After the previous commit, any return-specific processing
is now handled by pp_return itself, so S_return_lvalues only has to
worry about mortalising its args and grabbing the last arg in scalar
context.
Formerly there were two vars: newsp, which pointed to the slot before the
'1', and MARK, which pointed to the slot before the '3'. They now both
point to just before the '1'. So we only need to use one of them. Here
I've standardised on MARK, to make the code as similar as possible to that
in pp_leavesub, from which this code was forked back in 1999. For the same
reason I've set MARK to point to the '1' slot rather than the slot before
it, since that's what pp_leavesub does.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When an lvalue sub does an explicit return, currently pp_return
doesn't touch the args stack and instead tail calls S_return_lvalues()
which does both the leavesuby stuff (e.g. mortalise args) and the returny
stuff (e.g. shift the args down in list context).
Move the call to S_return_lvalues() further down in pp_return so that
the arg shifty stuff is done in pp_return now (like it is for non-lvalue
returns). This will allow us shortly to simply S_return_lvalues.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
pp_return() only needs to do the extra arg handling associated
with the args not being at the base of the stack frame. For example
for (1,2) { return 3,4 }
has to cope with 1,2,3,4 being on the stack.
Apart from handling junk, everything else - in particular pushing
&PL_sv_undef in scalar context if there are no return args - is already
done by Perl_pp_leavesub, which pp_return tail calls.
So reduce what pp_return does to the bare minimum. This makes one less
conditional branch in a few cases.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit:
1) makes the gimme of sort blocks, as specified by the pushed cx_gimme,
be G_SCALAR. Formerly it was likely to be G_ARRAY, as it inherited
whatever sort() was called as, and sort doesn't bother calling a sort
block unless sort was called in list context.
This change is largely cosmetic, as
a) the sort block is already compiled in scalar context; and
b) the code in S_sortcv() etc does its own return arg context
processing anyway, and assumes scalar context.
But it makes it consistent with sort SUB, which *does* set gimme to
G_SCALAR.
2) Makes use of the fact that a sort sub or block will always be
called as the first context in a new stackinfo, and such stackinfos always
have PL_stack_base[0] set to &PL_sv_undef as a guard.
So handling scalar context return (where zero args returned needs to be
converted into 1 PL_sv_undef arg) can be simplified by just always
accessing the last arg, *PL_stack_sp, regardless of whether 0,1,2+ args
were returned.
Note that some code making use of MULTICALL (e.g. List::Util) has already
been (possibly inadvertently) relying on this fact.
3) Remove the "Sort subroutine didn't return single value" fatal error.
This croak was removed from the sort BLOCK and sort NON-XS-SUB variants
in v5.15.5-82-g1715fa6, but the croak was left for XS sort subs.
That commit incorrectly asserted that for "sort BLOCK" and "sort
NON-XS-SUB", more than 1 arg could never be returned, but:
$ perl -e'sub f { return (1,2) } @a = sort f 1,2,3'
perl: pp_sort.c:1789: S_sortcv: Assertion `PL_stack_sp ==
PL_stack_base' failed.
That has been fixed by (2) above. By removing the croak from the XS branch
too, we make things consistent. This means that an XS sub which returns
more than 1 arg will just gets its return args be evaluated in scalar
context (so @return_args[-1] will be used), rather than being handled
specially.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When a sort function or code block returns an undef value (rather than the
typical -1,0,-1), you get the usual "Use of uninitialized value" warning.
Originally the message didn't say " ... in sort" because at the end of
running a sort sub, PL_op is NULL rather rather than pointing at the sort
op.
v5.15.3-364-gd4c6760 changed the sort sub return code in S_sortcv() et al
to temporarily set PL_op to point to the sort OP, which made
Perl_report_uninit() emit the desired " in sort" suffix.
However, this meant that PL_op and PL_curpad briefly referenced two
different CVs; since Perl_report_uninit() rummages around in pads looking
for lexicals, consts etc, this could lead to SEGVs.
v5.15.3-372-g1aa032b fixed that by temporarily setting PL_curpad to NULL
at the same time. However that then caused problems if the code dies
(e.g. if warnings are upgraded to errors) since the old PL_curpad value
wasn't being restored.
v5.17.6-7-g2f43ddf fixed that by wrapping the PL_curpad=NULL with
appropriate ENTER/SAVEVPTR(PL_curpad)/..../LEAVE where necessary.
However, this is starting to get quite complex, and in a hot piece of
code, and the 3 sort functions S_sortcv/S_sortcv_stacked/S_sortcv_xsub
are all diverging from each other in subtle and confusing ways.
This commit takes a different approach. It effectively reverts those three
commits (apart from the tests) and instead updates Perl_report_uninit()
to say "if PL_op is NULL, but the context stack indicates that we're
currently in a sort, then append " in sort" to the warning.
This is a lot less messy, and moves all the clutter from the two hot
functions S_sortcv/S_sortcv_stacked into a function that is only called
when we're emitting warnings.
|
| | |
| |
| |
| |
| |
| | |
Simplify the code in this function a bit.
It should have no functional effect, but will make the next commit
easier.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Currently when MULTICALL pushes a new stackinfo, it uses the si_type
PERLSI_SORT. This is probably just a hangover from when the MULTICALL code
was created from similar code used to implement sort.
Change it to use the new PERLSI_MULTICALL si_type.
The si_type value is mainly used for debugging/dumping purposes,
apart from a few places where we check for whether this is
the top stack (PERLSI_MAIN); or check for a sort BLOCK (cxix = 0,
CXt_NULL, PERLSI_SORT).
So this commit should have no immediate effect. It will in future
however allow us to detect whether we have a sort or a true MULTICALL.
|
| | |
| |
| |
| |
| |
| | |
Two blocks of error-reporting code both clean up the context state and
then croak with a similar message. Make the second block just goto the
first block instead.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
After merging in the functionality from pp_leavesublv and pp_return
into S_return_lvalues(), there were two context stack pointer decrement
conventions: before or after the POPSUB(). Both are wrong in different
ways, and will be more generally fixed up in later commits. For now,
standardise on a single form: that used by pp_leavesub and pp_leavesublv.
|
| | |
| |
| |
| | |
whitespace-only change.
|
| | |
| |
| |
| |
| |
| |
| | |
Currently about half the work involved in returning from an lvalue sub
call is done by the shared sub S_return_lvalues() function, while the
other half is duplicated in pp_leavesublv() and pp_return(). Move most of
that duplicated code into S_return_lvalues().
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
For returns within normal (rvalue) subs, handle the bulk of of the work by
falling through into pp_leavesub, rather than repeating most of the code.
So pp_return is now just responsible for popping any extra contexts and
shifting any return args back down to the base of the stack.
Return in lvalue subs, evals etc is unaffected.
|
| |/
|
|
|
|
|
|
|
|
|
|
| |
pp_last pops to the next relevant loop context type, or croaks.
Yet once it does this, it attempts to handle *all* context types
(subs, evals etc), even those which can never be the current
context.
Rip all this dead code out, and replace with an assertion that the
context is one of the loop types.
This dead code has been there since 5.000.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When I wrote this some years ago, I committed a logic error, so that a
constraint I thought applied was in fact somewhat different than what I
thought. The new comments give the proper constraint.
The code is taking the data furnished by unicode.org and massaging it
into tables usable by the perl interpreter. This bug can cause wrong
tables to be generated. Fortunately, this bug does not arise with
typical unicode.org data sets, so it hasn't shown up as a problem.
Fixing it makes no difference in the current Unicode version. I
discovered it only in compiling Unicode 1.1.5, somewhat tweaked by me,
so not the official data there either.
|
| |
|
|
|
|
|
|
|
| |
This test file creates a regex which includes the path of the build
directory. If that path includes regex metachars (e.g. blead_g++_quick)
then the test fails. Easily fixed with \Q...\E.
Monkey-patching here rather than waiting for upstream, since this is
currently breaking blead g++ smokes.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Unicode 8 version modifies this rule.
|
| | |
|
| | |
|
| | |
|
| | |
|
