Closes GH-16469
Working towards GH-16286
commit e0db221143b808d97bc3a44e9f0968c6308794b4
Author: Ilija Tovilo <ilija.tovilo@me.com>
Date: Fri Oct 25 22:48:20 2024 +0200
Move CFLAGS into ./configure command for consistency
commit 8ad67768250d181cd7fef30e0c866625bbd8ac94
Author: Ilija Tovilo <ilija.tovilo@me.com>
Date: Fri Oct 25 22:47:03 2024 +0200
Also upgrade nightly to macOS 13
commit 58a88ccb9f
Author: Ilija Tovilo <ilija.tovilo@me.com>
Date: Wed Oct 23 19:07:59 2024 +0200
Fix call to dc[n]gettext in tests with 0 $category
This causes a segfault on PHP-8.1
commit 611af05c50
Author: Ilija Tovilo <ilija.tovilo@me.com>
Date: Fri Dec 8 13:36:52 2023 +0100
[skip ci] Skip intermittently failing curl test on macOS
The test fails with "CURL ERROR: 56". I will create an issue for it shortly.
commit ec745178bb
Author: Ilija Tovilo <ilija.tovilo@me.com>
Date: Wed Oct 23 19:05:32 2024 +0200
Backport parts of 9999a0c for gettext
See 9999a0cb75
commit 5ce703496f
Author: Niels Dossche <7771979+nielsdos@users.noreply.github.com>
Date: Sun Jul 28 14:34:26 2024 +0200
Fix CI failure on macOS after Curl update
commit 714a3e7071
Author: Niels Dossche <7771979+nielsdos@users.noreply.github.com>
Date: Sat Jul 27 16:09:50 2024 +0200
Fix CI failure after Curl update (#15124)
commit 4f2eb921b9
Author: Niels Dossche <7771979+nielsdos@users.noreply.github.com>
Date: Thu May 23 22:20:37 2024 +0200
Fix GH-14307: Test curl_basic_024 fails with curl 8.8.0
Curl changed the behaviour, from the changelog:
- lib: make protocol handlers store scheme name lowercase curl/curl@c294f9c
From the docs: "The returned scheme might be upper or lowercase. Do
comparisons case insensitively."
Closes GH-14312.
commit 251195b41b
Author: Ayesh Karunaratne <ayesh@aye.sh>
Date: Thu Feb 1 02:03:55 2024 +0700
ext/curl: Fix failing tests due to string changes in libcurl 8.6.0
Upstream libcurl 8.6.0 contains a change[^1] that caused a test failure.
This fixes it by updating the test's `EXPECTF` to use a regex to account for both string patterns.
[^1]: https://github.com/curl/curl/commit/45cf4755e71f#diff-a8a54563608f8155973318f4ddb61d7328dab512b8ff2b5cc48cc76979d4204cL1683
Closes GH-13293.
commit fc5d83f2b1
Author: Christoph M. Becker <cmbecker69@gmx.de>
Date: Wed Oct 16 22:46:20 2024 +0200
Prepare for necessary move to macOS 13
GH will remove macOS 12 runner images as of December 3rd, so we prepare
for that.
Besides the obvious need to change the runner, we also suppress a
couple of warnings, because otherwise the build would fail due to
`-Werror`.
php_strip_url_passwd modifies url in-place. We cannot assume from
php_message_handler_for_zend that data is a temporary, modifiable string.
Fixes oss-fuzz #64209
Closes GH-12733
When redeclaring an overridden static property with a trait we're removing the
property from the class. However, because the property itself does not belong to
the class we must not free its associated data.
This issue is exposed by 9a250cc9d6 in PHP 8.3+ because duplicate static
properties in traits are no longer skipped, but redeclared.
Fixes GH-12468
When declaring the same static property with a doc block in a class and in a trait,
the doc block of the property in the class is leaked. While at it, possibly fix doc
comment for internal classes.
Close GH-12238
These tests intermittently crash asan. It might be due to some function invoking
dl(), which is known to crash lsan. It might also be something else, the version
of asan shipped with ubuntu 22.04 is flaky.
Addref to relevant fields before allocating any memory. Also only set/remove the
ZEND_ACC_HEAP_RT_CACHE flag after allocating memory.
Fixes GH-12073
Closes GH-12074
Normally, PHP evaluates all expressions in offsets (property or array), as well
as the right hand side of assignments before actually fetching the offsets. This
is well explained in this blog post.
https://www.npopov.com/2017/04/14/PHP-7-Virtual-machine.html#writes-and-memory-safety
For ??= we have a bit of a problem in that the rhs must only be evaluated if the
lhs is null or undefined. Thus, we have to first compile the lhs with BP_VAR_IS,
conditionally run the rhs and then re-fetch the lhs with BP_VAR_W to to make
sure the offsets are valid if they have been invalidated.
However, we don't want to just re-evaluate the entire lhs because it may contain
side-effects, as in $array[$x++] ??= 42;. In this case, we don't want to
re-evaluate $x++ because it would result in writing to a different offset than
was previously tested. The same goes for function calls, like
$array[foo()] ??= 42;, where the second call to foo() might result in a
different value. PHP behaves correctly in these cases. This is implemented by
memoizing sub-expressions in the lhs of ??= and reusing them when compiling the
lhs for the second time. This is done for any expression that isn't a variable,
i.e. anything that can (potentially) be written to.
Unfortunately, this also means that function calls are considered writable due
to their return-by-reference semantics, and will thus not be memoized. The
expression foo()['bar'] ??= 42; will invoke foo() twice. Even worse,
foo(bar()) ??= 42; will call both foo() and bar() twice, but
foo(bar() + 1) ??= 42; will only call foo() twice. This is likely not by design,
and was just overlooked in the implementation. The RFC does not specify how
function calls in the lhs of the coalesce assignment behaves. This should
probably be improved in the future.
Now, the problem this commit actually fixes is that ??= may memoize expressions
inside assert() function calls that may not actually execute. This is not only
an issue when using the VAR in the second expression (which would usually also
be skipped) but also when freeing the VAR. For this reason, it is not safe to
memoize assert() sub-expressions.
There are two possible solutions:
1. Don't memoize any sub-expressions of assert(), meaning they will execute
twice.
2. Throw a compile error.
Option 2 is not quite simple, because we can't disallow all memoization inside
assert(), as that would break assertions like assert($array[foo()] ??= 'bar');.
Code like this is highly unlikely (and dubious) but possible. In this case, we
would need to make sure that a memoized value could not be used across the
assert boundary it was created in. The complexity for this is not worthwhile. So
we opt for option 1 and disable memoization immediately inside assert().
Fixes GH-11580
Closes GH-11581
There are more places in zend_hash.c where the resize happened after some values on the HashTable struct were set.
I reordered them all, but writing a test for these would rely on the particular amount of bytes allocated at given points in time.
It's actually not php-cli specific, nor SAPI specific.
We should delay the registration of the function into the function table
until after the compilation was successful, otherwise the function is
mistakingly registered and a NULL dereference will happen when trying to
call it.
I based my test of Nikita's test, so credits to him for the test:
https://github.com/php/php-src/pull/8933#issuecomment-1259881008
Closes GH-10989.
The problem is that we're using the variable_ptr in the opcode handler
*after* it has already been destroyed. The solution is to create a
specialised version of zend_assign_to_variable which takes in two
destination zval pointers.
Closes GH-10524
Generators that suspended a fiber should not be dtor because they will be
executed during the fiber dtor.
Fiber dtor throws an exception in the fiber's context in order to unwind and
execute finally blocks, which will also properly dtor the generator.
Fixes GH-9916
zend_get_property_guard previously assumed that at least "str" has a
pre-computed hash. This is not always the case, for example when a
string is created by bitwise operations, its hash is not set. Instead of
forcing a computation of the hashes, drop the hash comparison.
Closes GH-10254
Co-authored-by: Changochen <changochen1@gmail.com>
Signed-off-by: George Peter Banyard <girgias@php.net>
Ilija Tovilo