* Port zend_cpuid for windows arm64
* Fix zend_atomic windows arm64 build
* Fix windows arm64 multiply
* Enable arm64 neon for windows in standard extension
* Enable arm64 neon for windows in zend_hash.c
* Workaround for msvc arm64 optimization bug
Closes GH-9115.
The ast node flag constants ZEND_DIM_ALTERNATIVE_SYNTAX and
ZEND_ENCAPS_VAR_DOLLAR_CURLY_VAR_VAR node have identical values (1<<1),
causing a deprecation notice to be incorrectly emitted before the fatal error
for unsupported syntax.
Fixes GH-9263
Explicitly check for AST_VAR/AST_DIM kind for future compatibility
`AST_PROP`/`AST_METHOD_CALL` and nullsafe variants can also be found in
encapsulated strings - currently they have no flags but they may have flags in
the future. This also clarifies that this deprecation warning can only happen
for AST_VAR/AST_DIM nodes for certain `attr` values.
This avoids a possible significant performance penalty, when some leaf function was observed, deep in the stack.
As a side effect, we are not iterating over prev_execute_data anymore and thus, non-observed fake frames, possibly on stack, cannot have any impact on the observer anymore (especially within zend_observer_fcall_end_all).
Saving the previous observer happens now directly on the VM stack. If there is any observer, function frames are allocated an extra zval (the last temporary), which will, on observed frames, contain the previous observed frame address.
* Remove ZEND_DVAL_TO_LVAL_CAST_OK
As far as I can see, this operation should always use the _slow method, and the results seem to be wrong when ZEND_DVAL_TO_LVAL_CAST_OK is enabled.
* update NEWS
This doesn't have an effect really, but humans and IDEs can struggle to see through the macro soup when they first interact with PHP's source code.
Moreover, this reduces some of the macro expansion hell when they appear in compiler warnings.
RAND_RANGE_BADSCALING() invokes undefined behavior when (max - min) >
ZEND_LONG_MAX, because the intermediate `double` might not fit into
`zend_long`.
Fix this by inlining a fixed version of the macro into Mt19937's range()
function. Fixing the macro itself cannot be done in the general case, because
the types of the inputs are not known. Instead of replacing one possibly broken
version with another possibly broken version, the macro is simply left as is
and should be removed in a future version.
The fix itself is simple: Instead of storing the "offset" in a `zend_long`, we
use a `zend_ulong` which is capable of storing the resulting double by
construction. With this fix the implementation of this broken scaling is
effectively identical to the implementation of php_random_range from a data
type perspective, making it easy to verify the correctness.
It was further empirically verified that the broken macro and the fix return
the same results for all possible values of `r` for several distinct pairs of
(min, max).
Fixes GH-9190
Fixes GH-9191
* Add Random\Random{Error,Exception} and Random\BrokenRandomEngineError
* Throw BrokenRandomEngineError
* Throw RandomException on seeding failure
* Throw RandomException when CSPRNG fails
* Remove unused include from ext/random/engine_combinedlcg.c
* Remove unused include from ext/random/engine_secure.c
* Remove unused include from ext/random/random.c
* [ci skip] Add ext/random Exception hierarchy to NEWS
* [ci skip] Add the change of Exception for random_(int|bytes) to UPGRADING
This removes the inconsistent and incorrectly working open basedir check
on pattern in glob. It means that an empty array will be returned even
if the whole pattern is outside the open basedir restriction.
* Fix PcgOneseq128XslRr64::__construct() definition in random.stub.php
The second parameter does not actually exist for a Oneseq PCG. It was removed
from the RFC before it went into voting.
* [ci skip] Add PcgOneseq128XslRr64 stub fix to NEWS
