This is a comprehensive refactoring of the error mechanism of the Intl extension.
By moving the prefixing of the current method/function being executed to actual error message creation by accessing the execution context, we get the following benefits:
- Accurate error messages indicating *what* call caused the error
- As we *always* "copy" the message, the `copyMsg` arg becomes unused, meaning we can reduce the size of the `intl_error` struct by 4 bytes.
- Saving it as a zend_string means we know the length of the message
- Remove the need to pass around a "function name" `char*` across multiple calls
- Use Intl's exception mechanism to generate exceptions for constructor call
- This removes the need for replacing the error handler
- Which didn't do anything anyway in silent mode, which required throwing non-descriptive exceptions
Also re-establishing exception throwing on IntlDateFormatter constructor
overwritten by accident most likely so postponing it for next major
release.
Close GH-12868
1. Update: http://www.php.net/license/3_01.txt to https, as there is anyway server header "Location:" to https.
2. Update few license 3.0 to 3.01 as 3.0 states "php 5.1.1, 4.1.1, and earlier".
3. In some license comments is "at through the world-wide-web" while most is without "at", so deleted.
4. fixed indentation in some files before |
Default them to IntlDateFormatter:FULL, which has value 0, which
was what you would get if you passed null to these arguments in
weak typing mode. The documentation called this ICU's default
date/time type.
We're starting to see a mix between uses of zend_bool and bool.
Replace all usages with the standard bool type everywhere.
Of course, zend_bool is retained as an alias.
As reported by cmb, this results a VC runtime warning. I don't
believe there's a problem here, as we only use calendar_long if
both calendar_is_null and calendar_obj are not set, but it doesn't
hurt to initialize it either...
Previously zend_parse_parameters (and FastZPP) would handle invalid
arguments depending on strict_types: With strict_types=1, a TypeError
is thrown, with strict_types=0 a warning is thrown and (usually) NULL
is returned. Additionally, some functions (constructors always and
other methods sometimes) opt-it to throwing regardless of strict_types.
This commit changes zpp to always generate a TypeError exception in
PHP 8.
Given that ICU is a set of lively developed libraries, that ICU 50.1
has been released on 2012-11-05, and PHP 7.4 is scheduled to be
released seven years after it, we consider it appropriate to ditch
these legacy versions.
Particularly, that would be a reasonable groundwork to implement part
two of the “Deprecate and remove INTL_IDNA_VARIANT_2003” RFC[1], namely
to default idn_to_ascii()'s and idn_to_utf8()'s $variant parameter to
INTL_IDNA_VARIANT_UTS46, which is not defined in ICU < 4.6.
See also the related discussion on internals@[2].
[1] <https://wiki.php.net/rfc/deprecate-and-remove-intl_idna_variant_2003>
[2] <http://news.php.net/php.internals/101626>ff
Introduces a ZEND_PARSE_PARAMS_THROW flag for zpp, which forces to
report FAILURE errors using a TypeException instead of a Warning,
like it would happen in strict mode.
Adds a zend_parse_parameters_throw() convenience function, which
invokes zpp with this flag.
Converts all cases I could identify, where we currently have
throwing zpp usage in constructors and replaces them with this API.
Error handling is still replaced to EH_THROW in some cases to handle
other, domain-specific errors in constructors.
The address of $this passed to drectly called internal constructor in execute_data->return_value.
Internal constructors should use ZEND_CTOR_MAKE_NULL() macro (insted of previous ZEND_NULL(EG(This))) to do the work.
This patch doesn't fix the problem for indirectly called constructors. e.g. parant::__construct().
