Make undef warnings thrown from inside xsubs more useful

[leonerd]

Calling e.g SvIV(sv) on an undefined sv will cause perl to print "Use of unininitialized value in ..." the most recent PL_op. If that's anywhere inside an XSUB (which it likely is), the most recent PL_op is the OP_ENTERSUB which brought us here, so it prints "in subroutine entry...". Not very helpful.

I would find this about a billion times more useful if it printed the CvNAME of the XSUB instead; so the output was something like

Use of uninitialized value in XSModule::xfunc() called at Some/Perl/File.pm line 1234.

[richardleach]

@leonerd - as mentioned on IRC, I'm happy to be the pupil to your teacher for this fix.

[Leont]

Yeah, this does sound like a helpful idea

[richardleach]

After a quick look, this seems to boil down to the contents of desc in Perl_report_uninit. https://github.com/Perl/perl5/blob/blead/sv.c#L17056

    if (PL_op) {
	desc = PL_op->op_type == OP_STRINGIFY && PL_op->op_folded
		? "join or string"
                : PL_op->op_type == OP_MULTICONCAT
                    && (PL_op->op_private & OPpMULTICONCAT_FAKE)
                ? "sprintf"
		: OP_DESC(PL_op);

So the fix is therefore to add an extra test for PL_op->op_type == OP_ENTERSUB, and if it's an XSUB being entered then set desc to its name? (Or is the op_type only ever going to be OP_ENTERSUB if an XSUB is being called? Which would slightly simplify matters.)

[leonerd]

So the fix is therefore to add an extra test for PL_op->op_type == OP_ENTERSUB, and if it's an XSUB being entered then set desc to its name?

That sounds reasonable.

(Or is the op_type only ever going to be OP_ENTERSUB if an XSUB is being called? Which would slightly simplify matters.)

Offhand I can't think of a situation but given how simple and cheap the test is to perform, it would be best to put that in anyway. It saves confusion in the rare case that it turns out it will happen on a PP sub.

[richardleach]

This is now looking very non-trivial. The approach was going to be:

1. Get the current CV:
   CV *cv = find_runcv(0);
2. Get the GV from that CV:
   GV *gv = CvGV(cv)
3. Do the rest of the stuffs.

But a simple demo resulted in a cv that doesn't point to the XSUB. Discussions on IRC revealed that cv was actually pointing to PL_main_cv, because:

<LeoNerd> presumably because that was the immediate caller
<ilmari> and pp_entersub doesn't push a context stack frame for xsubs
<LeoNerd> and the entersub op doesn't know it

The correct cv pointer is initially on the stack:

<ilmari> the stack is how pp_entersub gets it. literally the first thing pp_entersub does is dPOPss, 
then cv = MUTABLE_CV(SvRV(sv)); or cv = MUTABLE_CV(sv);

But:

<LeoNerd> We can't look at the stack because maybe the xsub has already been fiddling with it
<LeoNerd> Oh and anyway the OP_ENTERSUB itself popped that