* Emit EXT_STMT after each pipe stage, and attach the TMP var that holds the intermediary result
* Add ZEND_EXT_STMT to keeps_op1_alive as per review
* Fix leak with EXT_STMT when pipe result is unused
Co-authored-by: Ilija Tovilo <ilija.tovilo@me.com>
Since GH-17755 self and parent are compile-time resolved. We may now also
encounter this type error at runtime outside of the class itself.
Fixes GH-19304
When opcache is enabled, error handling is altered in the following ways:
* Errors emitted during compilation bypass the user-defined error handler
* Exceptions emitted during class linking are turned into fatal errors
Changes here make the behavior consistent regardless of opcache being enabled or
not:
* Errors emitted during compilation and class linking are always delayed and
handled after compilation or class linking. During handling, user-defined
error handlers are not bypassed. Fatal errors emitted during compilation or
class linking cause any delayed errors to be handled immediately (without
calling user-defined error handlers, as it would be unsafe).
* Exceptions thrown by user-defined error handlers when handling class linking
error are not promoted to fatal errors anymore and do not prevent linking.
Fixes GH-17422.
Closes GH-18541.
Closes GH-17627.
Co-authored-by: Tim Düsterhus <tim@bastelstu.be>
We previously changed the lineno of the property to the cpp argument, but now
also update the lineno for RECV and ASSIGN_OBJ. No test because we don't have a
way to enable lineno's in the opcode dump, and this is not easily testable
through error messages.
Pipe compilation uses a temporary znode with QM_ASSIGN to remove
references. Assert compilation wants to look at the operand AST and
convert it to a string. However the original AST is lost due to the
temporary znode. To solve this we either have to handle this specially
in pipe compilation [1], or store the AST anyway somehow.
Special casing this either way is not worth the complexity in my
opinion, especially as it looks like a dynamic call anyway due to the
FCC syntax.
[1] Prototype (incomplete) at
https://gist.github.com/nielsdos/50dc71718639c3af05db84a4dea6eb71
shows this is not worthwhile in my opinion.
Closes GH-18965.
Co-authored-by: Ilija Tovilo <ilija.tovilo@me.com>
Co-authored-by: Gina Peter Banyard <girgias@php.net>
Co-authored-by: Arnaud Le Blanc <arnaud.lb@gmail.com>
Co-authored-by: Tim Düsterhus <tim@tideways-gmbh.com>
Add recursion protection when emitting deprecation warnings for class
constants, since the deprecation message can come from an attribute that is
using the same constant for the message, or otherwise result in recursion.
But, internal constants are persisted, and thus cannot have recursion
protection. Otherwise, if a user error handler triggers bailout before the
recursion flag is removed then a subsequent request (e.g. with `--repeat 2`)
would start with that flag already applied. Internal constants can presumably
be trusted not to use deprecation messages that come from recursive attributes.
Fixes GH-18463
Fixes GH-17711
* zend_compile: Allow `(void)` in for’s initializer and loop expression
The initializer and loop expression of a `for()` loop only accept expressions,
but they act like statements in spirit - their results are completely ignored.
Allow `(void)` there to allow suppressing `#[\NoDiscard]`, since there is no
semantic ambiguity of what `(void)` returns anyways.
Fixesphp/php-src#18301
* zend_language_parser: Simplify `for()` grammar
The motivation for this is that types should be considered immutable.
The only times this is not valid is during compilation, optimizations (opcache), or destruction.
Therefore the "normal" type foreach macros are marked to take const arguments and we add mutable version that say so in the name.
Thus add various const qualifiers to communicate intent.
https://wiki.php.net/rfc/static-aviz
Optimally, this would be moved to zend_fetch_static_property_address(). However,
this isn't currently effective for opcache, because R and RW/W/UNSET cache slots
are merged. This will circumvent the visibility check if the cache is primed by
a R instruction.
Closes GH-16486
The check for `!fbc || (fbc->common.fn_flags & ZEND_ACC_VARIADIC)` is
performed after `fbc` is set to NULL, so this always returns true.
This results in `ZEND_FCALL_MAY_HAVE_EXTRA_NAMED_PARAMS` always being
set for unpack sends. Fix it by moving the flag updates to the point
before setting `fbc` to NULL.
Closes GH-17534.
