Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

intl_get_error_message() broken after MessageFormatter::formatMessage() fails #12020

Closed
TimWolla opened this issue Aug 22, 2023 · 3 comments
Closed

Comments

@TimWolla
Copy link
Member

Description

The following code:

<?php
var_dump(\MessageFormatter::formatMessage('en', 'some message with {invalid format}', []), intl_get_error_message());
var_dump(\MessageFormatter::formatMessage('en', 'some {wrong.format}', []), intl_get_error_message());

Resulted in this output:

bool(false)
string(12) "U_ZERO_ERROR"
bool(false)
string(12) "U_ZERO_ERROR"

But I expected this output instead:

bool(false)
string(128) "pattern syntax error (parse error at offset 19, after " message with {", before or at "invalid format}"): U_PATTERN_SYNTAX_ERROR"
bool(false)
string(116) "pattern syntax error (parse error at offset 6, after "some {", before or at "wrong.format}"): U_PATTERN_SYNTAX_ERROR"

see: https://onlinephp.io?s=s7EvyCjg5SpLLIpPKc0t0IjxTS0uTkxPdcsvyk0sKUktsrJKAzOh4hrqqXnqOgrqxfm5qQq5EDGF8sySDIXqzLyyxJzMFAWI-lqgquhYTR2FzLySnPj01JL41KKi_KJ4qB4NTU1rcq2tLi_Kz0vXI8EeAA%2C%2C&v=8.2.9%2C8.1.22%2C8.0.30%2C8.2.8%2C8.1.21

PHP Version

PHP 8.2.9

Operating System

No response

@TimWolla
Copy link
Member Author

I suspect this regressed in 536dbd7, but did not test.

@TimWolla
Copy link
Member Author

/cc @Girgias who authored the commit above.

TimWolla added a commit to WoltLab/Valinor that referenced this issue Aug 22, 2023
The actual error message is emitted by ICU / PHP which we do not have control
over.  We should not test that the upstream dependency returns stable error
messages, especially since error messages are for human consumption and thus
not part of the backwards compatibility contract.

see php/php-src#12020
@Girgias Girgias self-assigned this Aug 22, 2023
romm pushed a commit to CuyZ/Valinor that referenced this issue Aug 22, 2023
The actual error message is emitted by ICU / PHP which we do not have
control over. We should not test that the upstream dependency returns
stable error messages, especially since error messages are for human
consumption and thus not part of the backwards compatibility contract.

see php/php-src#12020
Girgias added a commit that referenced this issue Sep 3, 2023
…atter::formatMessage() fails

Passing NULL as the pointer to intl_error* will use the global error stack.
This is what we need to do instead of pushing it onto the temporary format object that is released.
Girgias added a commit that referenced this issue Sep 3, 2023
* PHP-8.1:
  Fixed bug GH-12020: intl_get_error_message() broken after MessageFormatter::formatMessage() fails
Girgias added a commit that referenced this issue Sep 3, 2023
* PHP-8.2:
  Fixed bug GH-12020: intl_get_error_message() broken after MessageFormatter::formatMessage() fails
Girgias added a commit that referenced this issue Sep 3, 2023
* PHP-8.3:
  Fixed bug GH-12020: intl_get_error_message() broken after MessageFormatter::formatMessage() fails
@Girgias
Copy link
Member

Girgias commented Sep 3, 2023

Fixed in a579fa8

@Girgias Girgias closed this as completed Sep 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants