Undefined subroutine &%s called, close to label '%s'

[richardleach]

#17839 requested a compile-time
warning for the situation whereby a single colon is accdentally typed
as a package separator when calling a function. For example:

package BOOP;
sub beep;
package main;
BOOP:beep();  # Meant to be BOOP::beep();

However, because of both Perl's syntax and the potential to populate the
stash at runtime, this falls somewhere between very difficult and
impossible. As an alternative, some enhanced fatal error wording was
requested and these commits attempt to provide that.

The above example would previously die with the message:

Undefined subroutine &main::beep called at ... line 4.

Now it dies with the message:

Undefined subroutine &main::beep called, close to label 'BOOP' at ... line 4.

For some of the same reasons mentioned, distinguishing this typo from
other errors at runtime - such as the target subroutine not being
present at all - is also nigh on impossible. The hope is that the
error message will give some additional clue when the error is the
result of a typo, without distracting the user in all other cases.

As part of these commits, some common DIE() calls in pp_entersub were
extracted into a new helper function, S_croak_undefined_subroutine, to
avoid adding (and slightly reduce) cold code bloating in pp_entersub.

[iabyn]

I'd prefer to see this split into two commits - the first to extract out the DIEes into a separate helper function, and the second to add the LABEL functionality.

I think the perldiag text (and perldelta) could be improved: give an actual example of the problem it's trying to flag, e.g. "Cfoo:bar() would be parsed as a label followed by an unqualified function name: C<foo: bar()>".

I'm somewhat twitchy that the message is generated even if the label doesn't immediately precede the function call but is merely in the same statement; E.g.

FOO: if ($x > 1 && foo()) { ... }

[richardleach]

I'd prefer to see this split into two commits - the first to extract out the DIEes into a separate helper function, and the second to add the LABEL functionality.

I think the perldiag text (and perldelta) could be improved: give an actual example of the problem it's trying to flag, e.g. "Cfoo:bar() would be parsed as a label followed by an unqualified function name: C<foo: bar()>".

I'll make those changes now.

I'm somewhat twitchy that the message is generated even if the label doesn't immediately precede the function call but is merely in the same statement;

Yes, I'm in two minds about it for that reason too. If, on balance, it looks like this will add more confusion than clarity, there's no point in adding it.

[iabyn]

On Mon, Dec 16, 2024 at 01:43:30PM -0800, Richard Leach wrote: I'll make those changes now.

Unless I'm misreading it, the 'detect label' code is actually part of the "Move pp_entersub DIE() code into S_croak_undefined_subroutine" commit.

> I'm somewhat twitchy that the message is generated even if the label doesn't immediately precede the function call but is merely in the same statement; Yes, I'm in two minds about it for that reason too. If, on balance, it looks like this will add more confusion than clarity, there's no point in adding it.

Perhaps the warning text should only added for the case where PL_curcop->op_next == PL_op ?

…

-- A power surge on the Bridge is rapidly and correctly diagnosed as a faulty capacitor by the highly-trained and competent engineering staff. -- Things That Never Happen in "Star Trek" #9