Currently, argument unpacking and named arguments cannot be mixed
at all. This relaxes the restriction to allow
foo(...$args, named: $arg). The variant foo(named: $arg, ...$args)
is still forbidden, because we can't ensure that positional
parameters come before named parameters in that case (without more
intrusive changes). Effectively this just enforces a required style,
as the order of unpack and named args doesn't matter for the cases
where both could be well-defined.
ML discussion: https://externals.io/message/114589
Closes GH-7009.
Since PHP 7.4 objects that have a destructor require two GC runs
to be collected. Currently the collection is delayed to the next
automatic GC run. However, in some cases this may result in a large
increase in memory usage, as in one of the cases of bug #79519.
See also bug #78933 and bug #81117 where the current behavior is
unexpected for users.
This patch will automatically rerun GC if destructors were encountered.
I think this should not have much cost, because it is very likely that
objects on which the destructor has been called really are garbage,
so the extra GC run should not be doing wasted work.
Closes GH-5581.
When the memory limit is restored during shutdown, we may still
be using a lot of memory. Ignore the failure at that point and
set it again after the MM is shut down, at which point memory
usage should be at its lowest point.
Updates the deprecation message for implicit incompatible float to int conversion from:
```
Implicit conversion from non-compatible float %.*H to int in %s on line %d
```
to
```
Implicit conversion from float %.*H to int loses precision in %s on line %d
```
Related: #6661
This test case did 100,000 includes of a non existing file to show the
memory leak; this is not necessary, because after the first failing
include, memory is not supposed to increase for further includes.
Closes GH-7088.
Currently interface methods with visibility `private` or `protected` fail
with an error message:
Access type for interface method A::b() must be omitted
However, explicitly setting visibility `public` is allowed and often desired.
This commit updates the error message to:
Access type for interface method A::b() must be public
As PHP has a minimum memory usage of 2M (size of allocator chunk),
setting a limit below that value is not meaningful and will be
automatically rounded up to the chunk size. Rather than doing this
silently, show the newly introduced error message.
The memory limit had to be increased to 2M for a number of tests.
tests/lang/bug45392 has been marked as XFAIL. This old bugfix is
not working as intended. The memory limit in main's `PG(memory_limit)`
differs from the one in zend_alloc. In zend_alloc the `AG(mm_heap)->limit`
is defined as `max(passed_value, ZEND_MM_CHUNK_SIZE)`. The check made in
an unclean shutdown will never be true unless the memory limit is lower
than ZEND_MM_CHUNK_SIZE, which happened to be the case in the test.
https://bugs.php.net/bug.php?id=45392https://github.com/php/php-src/commit/fcc0fdd125fdb9e1713f91d027fe07d680a0cf36
When the memory limit is reduced using an `ini_set("memory_limit", ..)`
below the currently allocated memory, the out-of-memory check overflowed.
Instead of implementing additional checks during allocation,
`zend_set_memory_limit()` now validates the new memory limit. When
below the current memory usage the ini_set call will fail and throw
a warning.
This is part of GH-7040.
This format matches against null bytes, and prevents the test
expectation from being interpreted as binary data.
bless_tests.php will automatically replace \0 with %0 as well.
Now that inheritance can throw deprecations again, these may be
converted to exception by a custom error handler. In this case
we need to convert the exception to a fatal error, as inheritance
cannot safely throw in the general case.
While the specified restriction was checked, the #[Attribute]
attribute did not specify the flags parameter, so that Reflection
returned incorrect information.
In particular, Attribute itself has a CLASS target, not an ALL
target.
The exception for null default values here exists to keep compatibility
with PHP < 7.1 where "Foo $bar = null" was the canonical way to create
a nullable parameter. If the parameter is actually "?Foo $bar = null",
then clearly compatibility with PHP < 7.1 is not a concern, and we
can throw a deprecation notice.
There was a loophole here when it came to usage with named arguments,
which was not intended. Close the loophole thoroughly by actually
dropping the default value from the signature entirely. The default
is still used to make the type nullable, but not for anything else.
This makes debug_print_backtrace() use the same formatting as exception
backtraces. The only difference is that the final #{main} is omitted,
because it wouldn't make sense for limited backtraces, and wasn't there
previously either.
Instead of manually implementing this, use the standard mechanism.
This has minor behavior changes (e.g. doing an isset() will now
return false instead of throwing) which are more in line with
typical behavior.
George Peter Banyard