Support 5.20 signatures

[shumphrey]

Currently PPI treats perl 5.20 signatures as PPI::Token::Prototype

I had a look through the code to see how this works.
PPI::Token::Whitespace returns a Prototype if the previous tokens imply it should be.

What is the best approach to support Signatures? Should there be a PPI::Token::Signature and should Prototype.pm return 'Signature' if it encounters a non prototype character? [^\$\@\%\\;]

[iynehz]

+1

This issue is affecting Perl::Critic Perl-Critic/Perl-Critic#591

[glauschwuffel]

Hi,

are there any news on this topic? I'd implement it if the approach described above is the right one.

[kberov]

For Perl::Critic to not complain when signatures are used, the workaround is still to put
[-Subroutines::ProhibitSubroutinePrototypes] in .perlcriticrc.

[glauschwuffel]

So, is the approach described above the way to go? If so, I'd go ahead and give it a try.

[kberov]

@glauschwuffel I don't know.
@adamkennedy should know or someone involved in the project.

[wchristian]

I'll have a think on this over the weekend.

[EvanCarroll]

Any progress on this?

[wchristian]

I never said which weekend. 😆

That said, we have THUNK on it.

And it's pretty fucked. In the completely context-free case there is no accurate way to determine whether it's a prototype of a signature, due to:

• signatures can contain arbitrary valid perl code
• prototypes can contain arbitrary characters of almost any type (see Web::Simple)
• the most common forms of either will look like sub meep (xxxx) {, so any other distinguishing features can be ignored as they'll be edge cases

Thus as far as the goal of "allow the policy to determine whether to complain about it being an old-style policy" goes, PPI can't actually help.

The primary way you should go about it is try and have the policy check for signatures being imported into the code space, at which point all prototypes ARE signatures, and prototypes look like attributes.

PPI could maybe be extended to answer the question if a prototype smells like a signature, which could be a number of factors like:

• doesn't look like a strict, documented, prototype
• looks a lot like a basic signature
• is contained within blocks into which the signatures feature was imported

It must also be kept in mind though that import analysis is fraught on account of imports being chainable through use()/require() of other modules and even the possibility of function calls that use()/require() modules into the caller space.

So, thoughts on this?

[EvanCarroll]

Being that signatures won't be experimental forever, perhaps we could simplify smells and look for non-sigils

• if so, assume it's a signature
• if not, assume it's a prototype

If this acceptable I'll look at patching.

[kberov]

"… look for non-sigils…"

• if so, assume it's a signature
• if not, assume it's a protype

[jtk18]

I was researching a fix for this issue and I stumbled upon this text here

To avoid ambiguity, when signatures are enabled the special syntax for prototypes is disabled. There is no attempt to guess whether a parenthesised group was intended to be a prototype or a signature.

So, according to that blurb, prototypes have a different syntax when signatures are enabled. I created the following tests:

#!/usr/bin/env perl

use strict;
use warnings;

sub blah($) {
}

blah();

Which outputs:

Not enough arguments for main::blah at ./proto.pl line 9, near "()"
Execution of ./proto.pl aborted due to compilation errors.

#!/usr/bin/env perl

use strict;
use warnings;

use feature qw(signatures);

sub blah($) {
}

blah();

Which outputs:

The signatures feature is experimental at ./signatures.pl line 8.
Too few arguments for subroutine 'main::blah' at ./signatures.pl line 11.

One would have to do a deeper dive for a better confirmation, but this at least shows that enabling the signatures feature changes what message is outputted.

[toddr]

Seems like PPR fixed it. It may be that we can only solve 98% of this. That would be better than nothing at all. Perfect is the enemy of good enough.

https://rt.cpan.org/Public/Bug/Display.html?id=125616

[oalders]

I think I would be happy with "good enough" on this issue.

[FGasper]

Hi all.

What is needed for motion on this one? This is a continual source of “itch”.