Releases: zephir-lang/php-zephir-parser
Releases · zephir-lang/php-zephir-parser
v2.0.2
v2.0.1
Added
- Added grammar rule for
<static>cast and method return type.STATICis a reserved keyword token, so<static>never reached the existingLESS IDENTIFIER GREATERcast rule and was rejected as a syntax error. A dedicatedLESS STATIC GREATERproduction now emits the literal"static"string in the same AST shape that<self>(and any other<IDENTIFIER>cast) produces, so the downstream compiler picks it up with no further parser-level changes. Enablespublic function foo() -> <static>for late-static-binding return types in Zephir
(zephir-lang/zephir#2505).
v2.0.0
Added
- Added support for array destructuring assignment syntax
let [a, b, c] = expr;,
matching PHP 7.1+ short list convention. Supports skipped slots (let [a, , c] = arr;)
and all-caps variable names. Parser-only; compiler code generation tracked in
zephir#2496
(#18) - Added
docs/grammar.ebnfcontaining the complete Zephir grammar in EBNF notation
for railroad diagram visualization via bottlecaps.de/rr/ui
(#106)
Fixed
- All-uppercase identifiers (e.g.
RBF,LU,A) are now accepted as class names,
method names, function names, variable names, property names, and parameters.
Previously the scanner emittedXX_T_CONSTANTfor any all-caps token and grammar
rules for name positions only acceptedXX_T_IDENTIFIER, causing a syntax error
(#39,
#180). - Class properties, constants, and methods can now be declared in any order inside a
class body. Previously only 9 fixed orderings were accepted; interleaving them (e.g.
a constant after a property) caused aParseException
(#26,
#181). (uchar)cast expressions no longer emit"unknown type"into the AST. The missing
XX_TYPE_UCHARcase has been added toxx_ret_type()inparser/parser.h
(#82,
#182).- String literals are now accepted as the method name in dynamic static method calls
(self::{"name"}(),ClassName::{"method"}(args),static::{"name"}()). Previously
onlyIDENTIFIERwas accepted in that position whilexx_mcall_expralready
supportedSTRING
(#22,
#183). - The
~(bitwise-NOT) operator no longer conflicts with the~"…"interned-string
literal (ISTRING) token. The re2c longest-match rule always resolved this correctly,
but the disambiguation is now documented with an explanatory comment inscanner.re
and covered by regression tests
(#23,
#184).