Currently, disabling a function only replaces the internal
function handler with one that throws a warning, and a few
places in the engine special-case such functions, such as
function_exists. This leaves us with a Schrödinger's function,
which both does not exist (function_exists returns false) and
does exist (you cannot define a function with the same name).
In particular, this prevents the implementation of robust
polyfills, as reported in https://bugs.php.net/bug.php?id=79382:
if (!function_exists('getallheaders')) {
function getallheaders(...) { ... }
}
If getallheaders() is a disabled function, this code will break.
This patch changes disable_functions to remove the functions from
the function table completely. For all intents and purposes, it
will look like the function does not exist.
This also renders two bits of PHP functionality obsolete and thus
deprecated:
* ReflectionFunction::isDisabled(), as it will no longer be
possible to construct the ReflectionFunction of a disabled
function in the first place.
* get_defined_functions() with $exclude_disabled=false, as
get_defined_functions() now never returns disabled functions.
Fixed bug #79382.
Closes GH-5473.
Mark "throw" used in expression context with a flag, and don't
treat it as a BB terminator in that case. This prevents us from
optimizing away the following opcodes as unreachable, which may
result in live ranges being dropped incorrectly.
Close GH-5450.
- zend_hash_find_ptr_lc(ht, zend_string *key)
- zend_hash_str_find_ptr_lc(ht, const char *str, size_t len)
Note that zend_hash_str_find_ptr_lc used to exist in zend_compile.c
as zend_hash_find_ptr_lc. When exporting this I figured it
was best to use the same conventions as the rest of zend_hash.h.
RFC: https://wiki.php.net/rfc/throw_expression
This has an open issue with temporaries that are live at the time
of the throw being leaked. Landing this now for easier testing and
will revert if we cannot resolve the issue.
Closes GH-5279.
This is only used in reflection, where doing a simple string check
is acceptable.
I'm also dropping the "dtor" printing in the reflection dump.
Dtors are just one of many magic methods, I don't think there's
a point in explicitly highlighting them, when the name is already
unambiguous.
For division (rather than modulus) we should check the double
value, otherwise the result might be zero after integer truncation,
but not zero as a floating point value.
This reverts commit bb43a3822e.
After thinking about this a bit more, this is now going to be
a complete solution for the "readonly properties" case, for example:
unset($foo->readOnly->bar);
should also be legal and
$foo->readOnly['bar'] = 42;
should also be legal if $foo->readOnly is not an array but an
ArrayAccess object.
I think it may be better to distinguish better on the BP_VAR flag
level. Reverting for now.
$a->b->c = 'd';
is now compiled the same way as
$b = $a->b;
$b->c = 'd';
That is, we perform a read fetch on $a->b, rather than a write
fetch.
This is possible, because PHP 8 removed auto-vivification support
for objects, so $a->b->c = 'd' may no longer modify $a->b proper
(i.e. not counting interior mutability of the object).
Closes GH-5250.
* PHP-7.4:
Check asserts early
identation fix
Call global code of preloaded script in global context
Avoid "Anonymous class wasn't preloaded" error by lazely loading of not preloaded part of a preloaded script
Currently, trait methods are aliased will continue to use the
original function name. In a few places in the codebase, we will
try to look up the actual method name instead. However, this does
not work if an aliased method is used indirectly
(https://bugs.php.net/bug.php?id=69180).
I think it would be better to instead actually change the method
name to the alias. This is in principle easy: We have to allow
function_name to be changed even if op array is otherwise shared
(similar to static_variables). This means we need to addref/release
the function_name separately, but I don't think there is a
performance concern here (especially as everything is usually
interned).
There is a bit of complication in opcache, where we need to make
sure that the function name is released the correct number of times
(interning may overwrite the name in the original op_array, but we
need to release it as many times as the op_array is shared).
Fixes bug #69180.
Fixes bug #74939.
Closes GH-5226.
As an exception, we allow "Type $foo = null" to occur before a
required parameter, because this pattern was used as a replacement
for nullable types in PHP versions older than 7.1.
Closes GH-5067.
In order of preference, the generated name will be:
new class extends ParentClass {};
// -> ParentClass@anonymous
new class implements FirstInterface, SecondInterface {};
// -> FirstInterface@anonymous
new class {};
// -> class@anonymous
This is intended to display a more useful class name in error messages
and stack traces, and thus make debugging easier.
Closes GH-5153.
RFC: https://wiki.php.net/rfc/static_return_type
The "static" type is represented as MAY_BE_STATIC, rather than
a class type like "self" and "parent", as it has special
resolution semantics, and cannot be cached in the runtime cache.
Closes GH-5062.
This helps to avoid unnecessary IS_REFERENCE checks.
This changes some notices "Only variables should be passed by reference" to exception "Cannot pass parameter %d by reference".
Also, for consistency, compile-time fatal error "Only variables can be passed by reference" was converted to exception "Cannot pass parameter %d by reference"
This is equivalent to checking ce->num_interfaces. The only subtle
moment is during inheritance, where num_interface may change when
parent interfaces are inherited. The check in zend_do_link_class
thus uses "interfaces", not "ce->num_interfaces".
Internal constants can be marked as CONST_DEPRECATED, in which
case accessing them will throw a deprecation warning.
For now this is only supported on global constants, not class
constants. Complain to me if you need to deprecate a class
constant...
Closes GH-5072.
Instead of having a completely independent encoding for type list
entries. This is going to use more memory, but I'm not particularly
concerned about that, as type unions that contain multiple classes
should be uncommon. On the other hand, this allows us to treat
top-level types and types inside lists mostly the same.
A new ZEND_TYPE_FOREACH macros allows to transparently treat list
and non-list types the same way. I'm not using it everywhere it could be
used for now, just the places that seemed most obvious.
Of course, this will make any future type system changes much simpler,
as it will not be necessary to duplicate all logic two times.
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.
