sort fns: simplify handing uninit warnings

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.

0 files changed, 0 insertions, 0 deletions