Remove arbitrary restriction that attributes cannot be applied
to property/constant groups.
The attribute applies to all elements of the group, just like
modifiers and types do.
See also https://externals.io/message/111914.
Closes GH-6186.
Instead of setting the old AST type to zero, replace the AST with
the compiled constexpr AST zval. This requires passing in a
zend_ast** instead of a zend_ast*.
This allows compiling ASTs containing constexprs multiple times
-- the second time, the existing compiled representation will be
resused.
This means we no longer need to copy the attributes AST for
promoted properties.
Make ReflectionAttribute::newInstance() respect the strict_types=1
declaration at the attribute use-site. More generally, pretend that
we are calling the attribute constructor from the place where the
attribute is used, which also means that the attribute location will
show up properly in backtraces and inside "called in" error information.
This requires us to store the attributes strict_types scope (as flags),
as well as the attribute line number. The attribute filename can be
recovered from the symbol it is used on. We might want to expose the
attribute line number via reflection as well.
See also https://externals.io/message/111915.
Closes GH-6201.
We missed the change to make this an Error exception in PHP 8,
but at least elevate it to a warning, to avoid a notice -> exception
jump at a later time.
Due to improvements to early binding, the opcode based check is
no longer accurate. Reuse the syntactic check we're already using
for declares instead.
The "member" string here does not necessarily have a pre-calculated
hash value. In particular this is not the case if the class has no
properties.
Fixes oss-fuzz #25546.
This addresses two issues:
* ~ throws for a number of types, and we should not compile-time
evaluate in that case. Add a check similar to what we do for
binary ops.
* Unary +/- may produce a different error message due to
canonicalization of the constant operand to the RHS. To avoid
this, put the constant operand on the RHS right away.
Fixes oss-fuzz #25649.
* The array "subject" of a function gets called $array.
* Further parameters should be self-descriptive if used
as a named parameter, and a full word, not an abbreviation.
* If there is a "bunch more arrays" variadic, it gets
called $arrays (because that's what was already there).
* A few functions have a variadic "a bunch more arrays,
and then a callable", and were already called $rest.
I left those as is and died a little inside.
* Any callable provided to an array function that acts
on the array is called $callback. (Nearly all were already,
I just fixed the one or two outliers.)
* array_multisort() is beyond help so I ran screaming.
These tests segfault with tracing JIT on Windows as of a recent
commit[1]. A link to a backtrace is available in a comment[2]. For
now, we mark these tests as XFAIL, to keep AppVeyor CI helpful.
[1] <7b0a053169>
[2] <7b0a053169 (commitcomment-42267637)>
If an argument error refers to a variadic argument, we normally
do not print the name of the variadic (as it is not referring to
an individual argument, but to the collection of all of them).
However, this was not the case for the userland argument type
error message, which did it's own formatting.
Closes GH-6101.
Both of these functions are well-defined when used with a single
array argument -- rejecting this case was an artificial limitation.
This is not useful when called with explicit arguments, but removes
edge-cases when used with argument unpacking:
// OK even if $excludes is empty.
array_diff($array, ...$excludes);
// OK even if $arrays contains a single array only.
array_intersect(...$arrays);
This matches the behavior of functions like array_merge() and
array_push(), which also allow calls with no array or a single
array respectively.
Closes GH-6097.
Applying the obvious fix ... however, I think we may need to
rething how we handle trampoline fcc for "f" zpp. It might make
sense to use fcc->function_handler == NULL for that case and
force it to be fetched in zend_call_function instead (it will
be reset to that after the call anyway). Otherwise we will keep
chasing these leaks, as it's the only instance where it's
necessary to free a zpp result.
Use the general zend_generator_throw_exception() helper for this.
Otherwise we don't handle the off-by-one opline correctly (should
we maybe just stop doing that?)
This is a followup to ad750c3bb6,
which fixed a different yield from exception handling problem that
happened to show up in the same test case from oss-fuzz #25321.
Now both issues should be fixed.
