| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
f23102e2d6 removed DOROP token (KEY_err) but related grammar remained
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
regardless of the fact that both have same value
their meaning is different and should not be mixed
|
|
|
|
|
| |
Usage of Bison's named references makes actions little bit easier
to read and maintain.
|
|
|
|
|
|
|
|
|
|
|
|
| |
The script alrady stripped out comments from bison 2.4 on the form
/* Line 1234 of yacc.c */
But bison 3.0 changed the comment syntax to
/* yacc.c:1234 */
Let's remove those too.
|
|
|
|
|
|
|
|
|
|
|
| |
This requires copying the `YY_CAST` and `YY_ATTRIBUTE_UNUSED` macros
from the generated code, and extracting the `yysymbol_kind_t` enum if
it's defined.
We must also handle token type names with escaped double-quotes in
them, since it now names the `YYEOF` and `YYUNDEF` tokens `"end of
file"` and `"invalid token"` instead of `$end` and `$undefined`,
respectively.
|
|
|
|
|
|
|
|
|
| |
This lets us replace the deprecated `%pure-parser` directive with
`%define api.pure`, and get rid of some other conditional code.
Bison is only required for developers hacking on the grammar, since we
check in the generated code. Bison 2.4 was released in 2008, and is
included in operating systems as old as Red Hat Enterprise Linux 6.
|
|
|
|
|
| |
Mostly in comments and docs, but some in diagnostic messages and one
case of 'or die die'.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The following code:
sub f ($x,$y) {
study;
}
used to compile as:
a <1> leavesub[1 ref] K/REFC,1 ->(end)
- <@> lineseq KP ->a
1 <;> nextstate(main 5 p:5) v:%,fea=7 ->2
2 <+> argcheck(2,0) v ->3
3 <;> nextstate(main 3 p:5) v:%,fea=7 ->4
4 <+> argelem(0)[$x:3,5] v/SV ->5
5 <;> nextstate(main 4 p:5) v:%,fea=7 ->6
6 <+> argelem(1)[$y:4,5] v/SV ->7
- <;> ex-nextstate(main 5 p:5) v:%,fea=7 ->7
7 <;> nextstate(main 5 p:6) v:%,fea=7 ->8
9 <1> study sK/1 ->a
- <1> ex-rv2sv sK/1 ->9
8 <$> gvsv(*_) s ->9
Following this commit, it compiles as:
a <1> leavesub[1 ref] K/REFC,1 ->(end)
- <@> lineseq KP ->a
- <1> ex-argcheck vK/1 ->7
- <@> lineseq vK ->-
1 <;> nextstate(main 5 p:5) v:%,fea=7 ->2
2 <+> argcheck(2,0) v ->3
3 <;> nextstate(main 3 p:5) v:%,fea=7 ->4
4 <+> argelem(0)[$x:3,5] v/SV ->5
5 <;> nextstate(main 4 p:5) v:%,fea=7 ->6
6 <+> argelem(1)[$y:4,5] v/SV ->7
- <;> ex-nextstate(main 5 p:5) v:%,fea=7 ->-
7 <;> nextstate(main 5 p:6) v:%,fea=7 ->8
9 <1> study sK/1 ->a
- <1> ex-rv2sv sK/1 ->9
8 <#> gvsv[*_] s ->9
All the ops associated with the signature have been put in their own
subtree, with an extra NULL ex-argcheck op "on top". The op on top
serves two purposes: first, it makes it easier for Deparse.pm etc to
spot siganure code; secondly, it may at some point in the future be
upgraded to OP_SIGNATURE when signatures get optimised. It's of type
ex-argcheck only because when being created it needs to be an op type
that's in class UNOP_AUX so that the created op will be suitable for
later optimising, and making it an ex-type associated with signatures
helps flag it as such.
There should be no functional changes apart from the shape of the
optree.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This op is of class OP_UNOP_AUX, Ops of this class have an op_aux pointer
which typically points to a variable-length malloced array of IVs,
UVs, etc. However in the specific case of OP_ARGCHECK the data stored
in the aux struct is fixed. So this commit casts the aux pointer to a
struct containing the relevant fields (number of parameters etc), rather
than referring to them as aux[0], aux[1] etc. This makes the code more
readable.
Should be no functional changes.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This exposes a GRAMSUBSIGNATURE top-level production from perly.y for
toke.c to consume, which parses a subroutine signature, inside the
parens.
This needed a small change to the existing rules, to pull out a rule
that handles all of the insides of the parens but not the parens
themselves.
(h/t to ilmari for the suggestion)
|
|
|
|
| |
No significant changes in the generated code since 3.0.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When doing a subparse, the tokenizer opens up the subexpression
with a '(' token, expecting the logic in yylex() to generate a ')'
once it sees the end of the subparsed string.
If the subparsed string includes an unmatched ')', this could confuse
the parser into finishing the expression and effectively exiting the
subparse without cleaning up (including popping the context)
To avoid that, create special bracketing tokens only generated for
a subparse and update the grammar to use those tokens in the cases
they might be used in a subparse.
This is an updated version of the patch that moves the FUNC rule
to where the original rule was and adds a test for non-regexp
subparses.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The items pushed onto the parser stack can be one of several types:
ival, opval, pval etc. The only remaining use of pval is when a "label:"
is encountered.
When an error occurs during parsing, ops on the parse stack get
automatically reaped these days as part of the OP slab mechanism;
but bare strings (pvals) still leak.
Convert this one remaining pval into an opval, making the toker return
an OP_CONST with an SV holding the label.
Since newSTATEOP() still expects a raw string for the label, the parser
just grabs the value returned by the toker and makes a copy of the
string from it, then immediately frees the OP_CONST and its associated
SV.
The leak was showing up in ext/XS-APItest/t/stmtasexpr.t, which expects
to parse a statement where labels are banned.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
RT #132141
Attributes such as :lvalue have to come *before* the signature to ensure
that they're applied to any code block within the signature; e.g.
sub f :lvalue ($a = do { $x = "abc"; return substr($x,0,1)}) {
....
}
So this commit moves sub attributes to come before the signature. This is
how they were originally, but they were swapped with v5.21.7-394-gabcf453.
This commit is essentially a revert of that commit (and its followups
v5.21.7-395-g71917f6, v5.21.7-421-g63ccd0d), plus some extra work for
Deparse, and an extra test.
See:
RT #123069 for why they were originally swapped
RT #132141 for why that broke :lvalue
http://nntp.perl.org/group/perl.perl5.porters/247999
for a general discussion about RT #132141
|
|
|
|
|
|
|
|
|
| |
Where an arrow is omitted between subscripts, if a parenthesised
subscript is followed by a braced one, PL_expect was getting set to
XBLOCK due to code intended for "foreach (...) {...}". This broke
bareword autoquotation, and the parsing of operators following the
braced subscript. Alter PL_expect from XBLOCK to XOPERATOR following
a parenthesised subscript. Fixes [perl #8045].
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The pumpking has determined that the CPAN breakage caused by changing
smartmatch [perl #132594] is too great for the smartmatch changes to
stay in for 5.28.
This reverts most of the merge in commit
da4e040f42421764ef069371d77c008e6b801f45. All core behaviour and
documentation is reverted. The removal of use of smartmatch from a couple
of tests (that aren't testing smartmatch) remains. Customisation of
a couple of CPAN modules to make them portable across smartmatch types
remains. A small bugfix in scope.c also remains.
|
|
|
|
|
| |
"whereis" is like "whereso" except that it performs an implicit
smartmatch.
|
|
|
|
|
| |
The names of ops, context types, functions, etc., all change in accordance
with the change of keyword.
|
| |
|
| |
|
|
|
|
|
|
| |
ASSIGNOP includes mutators like += as well as basic assignment
NPD
|
|
|
|
| |
then run ./regen_perly.pl to update perly files
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit f5727a1c71878a34f6255eb1a506c0b21af7d36f tried to make yada-yada
be parsed consistently as a term expression, but actually things are
more complicated than that. The tokeniser didn't accept yada-yada in
the right contexts to make it usable as an expression, and changing
that would require decisions on resolving ambiguities between yada-yada
and flip-flop. It's also documented as being a statement rather than
an expression, though with some incorrect information about ambiguities.
Overall it looks more like the intent was for yada-yada to be a statement.
This commit makes it grammatically treated as such, and also fixes up
the dubious parts of the documentation. [perl #132150]
|