In perl.git, the branch smoke-me/davem/sig_attr_croak has been created

<https://perl5.git.perl.org/perl.git/commitdiff/07431a29bfffc7fd1a18622437c1adf1658b6447?hp=0000000000000000000000000000000000000000>

        at  07431a29bfffc7fd1a18622437c1adf1658b6447 (commit)

- Log -----------------------------------------------------------------
commit 07431a29bfffc7fd1a18622437c1adf1658b6447
Author: David Mitchell <da...@iabyn.com>
Date:   Mon Feb 26 18:52:23 2018 +0000

    detect sub attributes following a signature
    
    RT #132760
    
    A recent commit (v5.27.7-212-g894f226) moved subroutine attributes back
    before the subroutine's signature: e.g.
    
        sub foo :prototype($$) ($a, $b) { ... }  # 5.18 and 5.28 +
        sub foo ($a, $b) :prototype($$) { ... }  # 5.20 .. 5.26
    
    This change means that any code still using an attribute following the
    signature is going to trigger a syntax error. However, the error, followed
    by error recovery and further warnings and errors, is very unfriendly and
    gives no indication of the root cause. This commit introduces a new error,
    "Subroutine attributes must come before the signature".
    
    For example, List::Lazy, the subject of the ticket, failed to compile
    tests, with output like:
    
        Array found where operator expected at blib/lib/List/Lazy.pm line 43,
        near "$$@)" (Missing operator before @)?)
        "my" variable $step masks earlier declaration in same statement at
        blib/lib/List/Lazy.pm line 44.
        syntax error at blib/lib/List/Lazy.pm line 36, near ") :"
        Global symbol "$generator" requires explicit package name (did you
        forget to declare "my $generator"?) at blib/lib/List/Lazy.pm line 38.
        Global symbol "$state" requires explicit package name (did you forget
        to declare "my $state"?) at blib/lib/List/Lazy.pm line 39.
        Global symbol "$min" requires explicit package name (did you forget to
        declare "my $min"?) at blib/lib/List/Lazy.pm line 43.
        Global symbol "$max" requires explicit package name (did you forget to
        declare "my $max"?) at blib/lib/List/Lazy.pm line 43.
        Global symbol "$step" requires explicit package name (did you forget
        to declare "my $step"?) at blib/lib/List/Lazy.pm line 43.
        Invalid separator character '{' in attribute list at
        blib/lib/List/Lazy.pm line 44, near "$step : sub "
        Global symbol "$step" requires explicit package name (did you forget
        to declare "my $step"?) at blib/lib/List/Lazy.pm line 44.
    
    But following this commit, it now just outputs:
    
        Subroutine attributes must come before the signature at
        blib/lib/List/Lazy.pm line 36.
        Compilation failed in require at t/append.t line 5.
        BEGIN failed--compilation aborted at t/append.t line 5.
    
    It works by:
    
    1) adding a boolean flag (sig_seen) to the parser state to indicate that a
       signature has been parsed;
    2) at the end of parsing a signature, PL_expect is set to XATTRBLOCK
       rather than XBLOCK.
    
    Then if something looking like one or more attributes is encountered
    by the lexer immediately afterwards, it scans it as if it were an
    attribute, but then if sig_seen is true, it croaks.

commit e7c19f715978cbb876fe94a4aa187cfbc3d9de54
Author: David Mitchell <da...@iabyn.com>
Date:   Mon Feb 26 13:50:50 2018 +0000

    subtly change meaning of XATTRBLOCK, XATTRTERM
    
    Currently they tell the toker that the next thing will be attributes,
    followed by an XBLOCK or XTERMBLOCK respectively.
    
    This commit subtly changes their meanings so that they indicate that
    attributes legally *might* follow. This makes the code which initially
    sets them slightly simpler (no need to check whether the next char is
    ':'), and the code elsewhere in yylex() which handles XATTR* only triggers
    if the next char is ':' anyway.
    
    Doing it this way will shortly make detection simpler of an attribute
    illegally following a signature.

commit a47e28076528d59784236975c73da1d513a8d0cd
Author: David Mitchell <da...@iabyn.com>
Date:   Thu Feb 22 14:44:51 2018 +0000

    rationalise subroutine parsing rules
    
    Now that the parser rules have been split into separate rules for subs
    under 'use feature "signatures"' and not, refine the rules to reflect the
    different regimes. In particular:
    
    1) no longer include 'proto' in the signature variants: as it happens the
    toker would never return a proto THING under signatures anyway, but
    removing it from the grammar makes it clearer what's expected and not
    expected.
    
    2) Remove 'subsignature' from non-sig rules: what used to happen before
    was that outside of 'use feature "signatures"', it might still try to
    parse a signature, e.g.
    
        $ perl5279 -we 'sub f :lvalue ($$@) { $x = 1 }'
        Illegal character following sigil in a subroutine signature at -e line
        1, near "($"
        syntax error at -e line 1, near "$$@"
    
    Now it's just a plain syntax error.

commit 3a68ba9556690bfe6e6f43cb9a0f366d09f5aff8
Author: David Mitchell <da...@iabyn.com>
Date:   Thu Feb 22 12:23:52 2018 +0000

    parse subs and signature subs separately
    
    Currently the toker returns a SUB or ANONSUB token at the beginning
    of a sub (or BEGIN etc). Change it so that in the scope of
    'use feature "signatures"', it returns a SIGSUB / ANON_SIGSUB token
    instead.
    
    Then in perly.y, duplicate the 2 rules containing SUB / ANONSUB
    to cope with these two new tokens.
    
    The net effect of this is to use different rules in the parser for
    parsing subs when signatures are in scope.
    
    Since the two sets of rules have just been cut and pasted, there should
    be no functional changes yet, but that will change shortly.

commit 3d8071e641a791cf2523d085efed5a1b22b1ab81
Author: David Mitchell <da...@iabyn.com>
Date:   Thu Feb 22 12:11:26 2018 +0000

    add Perl_init_named_cv() functiom
    
    This moves a block of code out from perly.y into its own function,
    because it will shortly be needed in more than one place.
    
    Should be no functional changes.

-----------------------------------------------------------------------

-- 
Perl5 Master Repository

Reply via email to