The new output is correct, though the fix here was rather accidental.
We still need a proper fix for bug #78308 on earlier branches, but
for now update the test to make the build green again.
Use ASCII case conversion instead of locale-dependent case conversion in
the following places:
* grapheme_stripos() and grapheme_strripos() in the "fast" path
* ldap_get_entries()
* oci_pconnect() for case folding of parameters when constructing a key
into the connection or session pool
* SoapClient: case folding of function names
* get_meta_tags(): case conversion of property names
* http stream wrapper: header names
* phpinfo(): anchor names
* php_verror(): docref URLs
* rfc1867.c: Content-Type boundary parameter name
* streams.c: stream protocol names
Using locale-dependent case folding for these cases is either
unnecessary or actively incorrect. These functions could have
misbehaved when used with certain locales (e.g. Turkish).
Closes GH-7511.
We must not assume that `usearch_last()` gives the proper result for
negative offsets. Instead we'd need to continue to search backwards
(`usearch_previous`) until we find a proper match. However, apparently
searching backwards is broken, so we work around by searching forward
from the start of the string until we pass the `offset_pos`, and then
use the previous result.
Closes GH-7189.
GMT+00:00 is recognized by ICU, and is normalized to GMT. There are no
issues when GMT+00:00 is passed to `IntlTimeZone::createTimeZone()`,
but passing it to IntlDateFormatter::__construct() causes a failure,
since there is an additional check regarding the validity. While
checking the validity of the result of `TimeZone::createTimeZone()`[1]
is a good idea, comparing the IDs is overly restrictive. Instead we
just check that the timezone is supported by ICU.
[1] <https://unicode-org.github.io/icu-docs/apidoc/dev/icu4c/classicu_1_1TimeZone.html#a35da0507b62754ffe5d8d59c19775cdb>
Closes GH-7190.
Both of these just forward to the default implementation, so
just use that directly. This is simpler and benefits from the
special-casing of the default implementation.
These tests fail with the following diff:
========DIFF========
date: Tuesday, July 7, 2009 8:41:13 PM EDT
002+ msgf: Wednesday, July 8, 2009 12:41:13 AM utc
002- msgf: Tuesday, July 7, 2009 8:41:13 PM usnyc
========DONE========
FAIL Bug #58756: w.r.t MessageFormatter [ext/intl/tests/bug58756_MessageFormatter_variant2.phpt]
========DIFF========
001+ quinta-feira, 17 de maio de 2012 4:35:36 da tarde utc
001- quinta-feira, 17 de maio de 2012 5:35:36 da tarde ptlis
========DONE========
FAIL MessageFormat accepts IntlCalendar args [ext/intl/tests/msgfmt_format_intlcalendar_variant4.phpt]
That is, it appears that the timezone does not get applied. I don't
know why this happens, and don't want to spend more time trying to
figure this out.
Before the zval -> zend_object migration, this code used macros
like FORMATTER_METHOD_FETCH_OBJECT_NO_CHECK, which internally
clear the error. Now that they are no longer used, we need to
manually clear the error.
* Fix return type of php_user_filter::onCreate()
* Fix return type of mysqli::init()
* Fix return type of UConverter::fromUCallback() and UConverter::toUCallback()
