Split class_constant from constant production

Make encapsed strings fully dereferencable

This allows operations that were previously allowed on constant
strings on interpolated strings as well.

Clean up the generation of the parsers

Prefer '%define api.value.type' to '#define YYSTYPE', so that Bison
know the type.

Use '%code requires' to declare what is needed to defin

Clean up the generation of the parsers

Prefer '%define api.value.type' to '#define YYSTYPE', so that Bison
know the type.

Use '%code requires' to declare what is needed to define the api.value.type
(that code is output in the generated header before the generated
definition of YYSTYPE).

Prefer '%define api.prefix' inside the grammar file to '-p' outside,
as anyway the functions defined in the file actually use this prefix.

Prefer `%param` to both `%parse-param` and `%lex-param`.

Closes GH-5138

show more ...

Bison: enable all the warnings and fix them

First, fix 5547d361208d90e12d53bb62bb2ffbbff9b93ca0: the definition of
YFLAGS was not passed into the Makefile: AC_SUBST does not suffice, we

Bison: enable all the warnings and fix them

First, fix 5547d361208d90e12d53bb62bb2ffbbff9b93ca0: the definition of
YFLAGS was not passed into the Makefile: AC_SUBST does not suffice, we
need PHP_SUBST_OLD. While at it, allow to pass variable and value at
the same time.

Then pass -Wall to bison, rather than only -Wempty-rules.

Use %precedence where associativity is useless.

Remove useless %precedence.
GH-5138

show more ...

Use "%empty" in the parsers, instead of comments

The annotation %empty is properly enforced: warnings when it's
missing, and errors when it's inappropriate. Support for %empty was
i

Use "%empty" in the parsers, instead of comments

The annotation %empty is properly enforced: warnings when it's
missing, and errors when it's inappropriate. Support for %empty was
introduced in Bison 3.0.

Pass -Wempty-rule to Bison.

Closes GH-5134

show more ...

Use "%define parse.error verbose"

The YYERROR_VERBOSE macro will no longer be supported in Bison 3.6.
It was superseded by the "%error-verbose" directive in Bison 1.875
(2003-01-01).

Use "%define parse.error verbose"

The YYERROR_VERBOSE macro will no longer be supported in Bison 3.6.
It was superseded by the "%error-verbose" directive in Bison 1.875
(2003-01-01). Bison 2.6 (2012-07-19) clearly announced that support
for YYERROR_VERBOSE would be removed. Note that since Bison 3.0
(2013-07-25), "%error-verbose" is deprecated in favor of "%define
parse.error verbose".

Closes GH-5125.

show more ...

Handle one more case I missed

Make class name references use the class_name production

Throw a compile error for "static" references instead, where it
isn't already the case.

Also extract the code that does

Make class name references use the class_name production

Throw a compile error for "static" references instead, where it
isn't already the case.

Also extract the code that does that -- we have quite a few places
where we get a const class ref and require it to be default.

show more ...

Don't use yystrlen()

This is unnecessary and not available when GLR is used.

Implement union types

According to RFC: https://wiki.php.net/rfc/union_types_v2

The type representation now makes use of both the pointer payload
and the type mask at the same t

Implement union types

According to RFC: https://wiki.php.net/rfc/union_types_v2

The type representation now makes use of both the pointer payload
and the type mask at the same time. Additionall, zend_type_list is
introduced as a new kind of pointer payload, which is used to store
multiple class types. Each of the class types is a tagged pointer,
which may be either a class name or class entry. The latter is only
used for typed properties, while arguments/returns will instead use
cache slots. A type list can contain a mix of both names and CEs at
the same time, as not all classes may be resolvable.

One thing this is missing is support for union types in arginfo
and stubs, which I want to handle separately.

I've also dropped the special object code from the JIT implementation
for now -- I plan to add this back in a different form at a later time.
For now I did not want to include non-trivial JIT changes together
with large functional changes.

Another possible piece of follow-up work is to implement "iterable"
as an internal alias for "array|Traversable". I believe this will
eliminate quite a few special-cases that had to be implemented.

Closes GH-4838.

show more ...

new_variable '{' expr '}' is deprecated as well

Curly brace syntax for accessing array elements and string offsets is
deprecated [1]; this should also be the case for respective `new`

new_variable '{' expr '}' is deprecated as well

Curly brace syntax for accessing array elements and string offsets is
deprecated [1]; this should also be the case for respective `new`
expressions.

This issue has been reported by brzuchal@php.net.

[1] <https://wiki.php.net/rfc/deprecate_curly_braces_array_access>

show more ...

Don't specify precedence for T_INC/T_DEC

As these do not operate on expressions, precedence is meaningless
for them.

Fixed bug #78363

Deprecate alternative array access syntax

RFC: https://wiki.php.net/rfc/deprecate_curly_braces_array_access

Emit T_BAD_CHARACTER for unexpected characters

Avoid having holes in the token stream which are annoying and
inefficient to reconstruct on the consumer side.

Replace ZEND_ASSIGN_ADD (and others) by ZEND_ASSIGN_OP, ZEND_ASSIGN_DIM_OP, ZEND_ASSGIN_OBJ_OP and ZEND_ASSIGN_STATIC_PROP_OP

Use %define api.pure instead of %pure-parser

%pure-parser is deprecated. In our case there is no difference between
true & full, as we don't use locations.

Implement spread operator in arrays

RFC: https://wiki.php.net/rfc/spread_operator_for_array

Closes GH-3640.

Deprecate left-associative ternary

Deprecate nesting ternary operators without explicit parentheses.

RFC: https://wiki.php.net/rfc/ternary_associativity

Implement arrow functions

Per RFC: https://wiki.php.net/rfc/arrow_functions_v2

Co-authored-by: Levi Morrison <levim@php.net>
Co-authored-by: Bob Weinand <bobwei9@hotmail.com>

Deprecate unparenthesized concatenation and addition/subtraction

Implementing RFC https://wiki.php.net/rfc/concatenation_precedence

Change the precedence of concatenation

This implements RFC https://wiki.php.net/rfc/concatenation_precedence

Revert "Switch to bison location tracking"

This reverts commit e528762c1c59bc0bd0bd6d78246c14269630cf0f.

Dmitry reports that this has a non-trivial impact on parsing
overhead, e

Revert "Switch to bison location tracking"

This reverts commit e528762c1c59bc0bd0bd6d78246c14269630cf0f.

Dmitry reports that this has a non-trivial impact on parsing
overhead, especially on 32-bit systems. As we don't have a strong
need for this change right now, I'm reverting it.

See also comments on
https://github.com/php/php-src/commit/e528762c1c59bc0bd0bd6d78246c14269630cf0f.

show more ...

Switch to bison location tracking

Locations for AST nodes are now tracked with the help of bison
location tracking. This is more accurate than what we currently do
and easier to exte

Switch to bison location tracking

Locations for AST nodes are now tracked with the help of bison
location tracking. This is more accurate than what we currently do
and easier to extend with more information.

A zend_ast_loc structure is introduced, which is used for the location
stack. Currently it only holds the start lineno, but can be extended
to also hold end lineno and offset/column information in the future.

All AST constructors now accept a zend_ast_loc* as first argument, and
will use it to determine their lineno. Previously this used either the
CG(zend_lineno), or the smallest AST lineno of child nodes.

On the parser side, the location structure for a whole rule can be
obtained using the &@$ character salad.

show more ...

Remove unnecessary precedence/associativity annotations

Some of these are entirely unnecessary. Some specify an associativity
for operators where the concept doesn't make sense and has n

Remove unnecessary precedence/associativity annotations

Some of these are entirely unnecessary. Some specify an associativity
for operators where the concept doesn't make sense and has no effect:
Explicit associativity is only meaningful for binary operators. For
unary operators and constrained operations like instanceof or assignment
the associativity specification has no effect and only serves to confuse.

For example assignments were specified as %left, even though they will
actually behave as right-associative due to the variable requirement on
the LHS. Similarly instanceof was specified as %nonassoc, but it will
behave as left-associative, due to the restrictions places on the RHS.

show more ...