Support acquiring a Closure to a callable using the syntax
func(...), $obj->method(...), etc. This is essentially a
shortcut for Closure::fromCallable().
RFC: https://wiki.php.net/rfc/first_class_callable_syntax
Closes GH-7019.
Co-Authored-By: Nikita Popov <nikita.ppv@gmail.com>
Add support for new expressions inside parameter default values,
static variable initializers, global constant initializers and
attribute arguments.
RFC: https://wiki.php.net/rfc/new_in_initializers
Closes GH-7153.
Because php supports doc comments on class constants, I believe it would also
make sense to support them on enum cases.
I don't have strong opinions about whether attributes should be moved to be the
last element or whether the doc comment should go after the attribute,
but the ast will likely change again before php 8.1 is stable.
So far, all attributes are the last ast child node.
I didn't notice that doc comments weren't implemented due to
https://github.com/php/php-src/pull/6489 being a large change.
https://wiki.php.net/rfc/enumerations
did not mention whether or not doc comments were meant to be supported
We're starting to see a mix between uses of zend_bool and bool.
Replace all usages with the standard bool type everywhere.
Of course, zend_bool is retained as an alias.
See https://github.com/nikic/php-ast/pull/181
> Hm, I'm thinking it would make more sense to change the structure in php-src.
> All the function types have consistent AST structure, but there's no reason at
> all why classes should be consistent with functions.
It's unusual to have an unused child node between other child nodes that are
used (for name, extends, implements, and attributes of AST_CLASS)
> That gap is a leftover from a previous refactoring. An earlier version of
> attributes extended `zend_ast_decl` with a new member called `attributes` and
> therefore did not need to handle functions and classes in different ways.
Closes GH-6088
Voidification of Zend API which always succeeded
Use bool argument types instead of int for boolean arguments
Use bool return type for functions which return true/false (1/0)
Use zend_result return type for functions which return SUCCESS/FAILURE as they don't follow normal boolean semantics
Closes GH-6002
From an engine perspective, named parameters mainly add three
concepts:
* The SEND_* opcodes now accept a CONST op2, which is the
argument name. For now, it is looked up by linear scan and
runtime cached.
* This may leave UNDEF arguments on the stack. To avoid having
to deal with them in other places, a CHECK_UNDEF_ARGS opcode
is used to either replace them with defaults, or error.
* For variadic functions, EX(extra_named_params) are collected
and need to be freed based on ZEND_CALL_HAS_EXTRA_NAMED_PARAMS.
RFC: https://wiki.php.net/rfc/named_params
Closes GH-5357.
I haven't tracked down in detail where the interaction with
increment_function comes from, but the root problem here is failure
to handle the illegal offset type exception.
As part of my work on typed class constants, I wanted to make a
separate pull request for unrelated changes.
These include:
* Moving from ast->child[0]->attr to ast->attr
* Making zend_ast_export_ex() export class constants' visibility
* Extracting an additional zend_compile_class_const_group() function
Closes GH-5812.
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.
* Change a number of "resource used as offset" notices to warnings,
which were previously missed.
* Throw the "resource used as offset" warning for isset() as well.
* Make array_key_exists() behavior with regard to different key
types consistent with isset() and normal array accesses. All key
types now use the usual coercions and array/object keys throw
TypeError.
Closes GH-4887.
