BBC: LNATION/Devel-Required-0.15.tar.gz fails with perl 5.31.10

[eserte]

See http://fast-matrix.cpantesters.org/?dist=Devel-Required%200.15 --- there are no pass reports with released 5.31.10 (though there are some passes for pre-release versions of 5.31.10).

[hvds]

The code does this in a BEGIN block to find the WriteMakefile() sub to overload:

    my $subname= caller() . '::WriteMakefile';

.. and the caller() is now returning Devel::Required; changing that to caller(2) allows tests to pass (but I don't know offhand if that works on older perls).

@iabyn this appears to be further fallout from "avoid identical stack traces". I'm a bit concerned that problems like this may affect a bunch of non-CPAN code too, and could be hard for people to diagnose without conscious awareness of the change. Is there anything we can do to mitigate that?

[Edited "caller(2)" to "caller(1)" after deciding my diagnostics had introduced an extra stack frame, then back again when I found that was wrong.]

[iabyn]

On Sun, Mar 29, 2020 at 07:30:40AM -0700, Hugo van der Sanden wrote: @iabyn this appears to be further fallout from "avoid identical stack traces". I'm a bit concerned that problems like this may affect a bunch of non-CPAN code too, and could be hard for people to diagnose without conscious awareness of the change. Is there anything we can do to mitigate that?

Not really, apart from pulling the fix altogether. Previously perl screwed up the stack backtrace within BEGINs; now caller() returns the correct values. Seems like a binary choice - keep the fix, or revert to the broken behaviour for backwards compatibility. Of course if we revert now, we screw up any distributions which have just been fixed to match blead behaviour.

…

-- Counsellor Troi states something other than the blindingly obvious. -- Things That Never Happen in "Star Trek" #16

[hvds]

On Sun, Mar 29, 2020 at 07:30:40AM -0700, Hugo van der Sanden wrote:

I'm a bit concerned that problems like this may affect a bunch of non-CPAN code too, and could be hard for people to diagnose without conscious awareness of the change. Is there anything we can do to mitigate that?

Not really, apart from pulling the fix altogether. Previously perl screwed up the stack backtrace within BEGINs; now caller() returns the correct values. Seems like a binary choice - keep the fix, or revert to the broken behaviour for backwards compatibility. Of course if we revert now, we screw up any distributions which have just been fixed to match blead behaviour.

Ok, I've opened https://rt.cpan.org/Ticket/Display.html?id=132269 against Devel::Required.

I think we'll need at least to highlight this prominently in 5.32 perldelta.

[karenetheridge]

Is the underlying cause of this the same as in #17663?

[hvds]

Is the underlying cause of this the same as in #17663?

#17663 appears to be 3 distinct failures. From the information in that ticket, I'd say that CGI-ProgressBar is almost certainly the same as the case here; App-Framework-Lite is probably the same; and for DBIx-Class I have no clue.

[Leont]

Is the underlying cause of this the same as in #17663?

Yes.

[karenetheridge]

@iabyn this appears to be further fallout from "avoid identical stack traces". I'm a bit concerned that problems like this may affect a bunch of non-CPAN code too, and could be hard for people to diagnose without conscious awareness of the change. Is there anything we can do to mitigate that?

Not really, apart from pulling the fix altogether. Previously perl screwed up the stack backtrace within BEGINs; now caller() returns the correct values. Seems like a binary choice - keep the fix, or revert to the broken behaviour for backwards compatibility. Of course if we revert now, we screw up any distributions which have just been fixed to match blead behaviour.

As per #17663 (comment), there is still an open question as to whether this is a fix at all, or an undesired behaviour. I don't know the answer, but this was a thoughtful post and no one has responded to the concerns raised yet.

[xsawyerx]

This is, IMHO, a correct fix, as I expressed in #17663.

[jkeenan]

On 4/26/20 2:57 AM, Sawyer X wrote: This is, IMHO, a correct fix, as I expressed in #17663 <#17663>.

Earlier in this ticket, @hvds observed that we need to "to highlight [the correction to caller()'s behavior] prominently in 5.32 perldelta." ack-ing pod/perl pod/perl5031*delta.pod for `caller`, the only thing I can find is: ``` =item caller Like L<C<__FILE__>|/__FILE__> and L<C<__LINE__>|/__LINE__>, the filename and line number returned here may be altered by the mechanism described at L<perlsyn/"Plain Old Comments (Not!)">. ``` ... which to me doesn't seem to be sufficient. Could we get something better? Thank you very much. Jim Keenan

[khwilliamson]

Is this now not a blocker, since commits for https://github.com/Perl/perl5/issues/17663 have been reverted?