Add a test to ICU4C for handling of lone surrogates.
Incidentally fix uninitialized-memory bug in MessageFormatter
(initialize `errors` to nullptr)
Co-authored-by: Frank Tang <ftang@chromium.org>
Add MessageFormatter::Builder::setErrorHandlingBehavior() method
and a new enum type MessageFormatter::UMFErrorHandlingBehavior
to denote strict or best-effort behavior.
The reason for adding a single method that takes an enum is to allow
for the possibility of more error handling modes in the future.
Co-authored-by: Markus Scherer <markus.icu@gmail.com>
1. Rewrite to use LocalPointer to prevent memory leak
2. Rewrite the if/else to switch to make the logic clear
3. Delete the rule if not remember inside the rule set to fix memory
leak.
4. Check base value calculation to avoid int64_t overflow.
5. Add memory leak test
This also updates the spec tests from the current version of the MFWG
repository and removes some duplicate tests.
Spec tests now reflect the message-format-wg repo as of
5612f3b050
It also updates both the ICU4C and ICU4J parsers to follow the
current test schema in the conformance repository.
This includes adding code to both parsers to allow `src` to be
either a single string or an array of strings (per
https://github.com/unicode-org/conformance/pull/255 ),
and eliminating `srcs` in tests.
It also includes other changes to make updated spec tests pass:
ICU4C: Allow trailing whitespace for complex messages, due to spec change
ICU4C: Parse number literals correctly in Number::format
ICU4J: Allow trailing whitespace after complex body, per spec change
ICU4C: Fix bug that was assuming an .input variable can't have a reserved annotation
ICU4C: Fix bug where unsupported '.i' was parsed as an '.input'
ICU4C/ICU4J: Handle markup with space after the initial left curly brace
ICU4C: Check for duplicate variant errors
ICU4C/ICU4J: Handle leading whitespace in complex messages
ICU4J: Treat whitespace after .input keyword as optional
ICU4J: Don't format unannotated number literals as numbers
Having commented-out checks for things that don't even need to be
checked serves no purpose.
MSVC floating point optimizations don't need to be set, /fp:precise is
the default and has been so for a very long time now:
https://learn.microsoft.com/en-us/cpp/build/reference/fp-specify-floating-point-behavior?view=msvc-140
ICU4C requires C++17 and there aren't any compilers capable of that
without namespace support so there's no need to check that.
Both std::u16string_view and std::wstring_view are possible matches for
UnicodeString as a template parameter, but adding an explicit overload
avoids both having to make that choice and taking the detour through
creating any string view at all.
Enhance #if for locdispnames.cpp
ICU-22721 Enhance #if for locdispnames.cpp, remove auto-generate file in local git.
ICU-22721 Enhance #if for locdispnames.cpp.
ICU-22721 Enhance #if for locdispnames.cpp, revert old-xmls.tar.bz2 file from main branch.
ICU-22721 Enhance #if for locdispnames.cpp
Enhance #if for locdispnames.cpp
ICU-22721 Enhance #if for locdispnames.cpp, remove auto-generate file in local git.
ICU-22721 Enhance #if for locdispnames.cpp.
ICU-22721 Enhance #if for locdispnames.cpp, revert old-xmls.tar.bz2 file from main branch.
As was pointed out in PR #3106, the standard doesn't mandate the
existence of std::char_traits<uint16_t> and libc++ did actually
deprecate it in release 18 and delete it in release 19.
As ICU4C uses this for backward compatibility for old code that still
depends on setting -DUCHAR_TYPE=uint16_t it'd be nice to keep using it
as long as possible but once it's gone from the standard library there
isn't really much useful that ICU4C could do about that so conditionally
compiling the code when the standard library version is old enough
should suffice for keeping backward compatibility for yet some time.
https://github.com/llvm/llvm-project/commit/cce062d
When passing a string literal to any of the legacy constructors that
take just a plain pointer to a UTF-16 string it becomes necessary to
iterate through the string to find its length, even though this length
was known to the compiler (which just has no way of passing it on to the
constructor).
But when calling the new templated string view constructor instead it
becomes possible for the compiler to use the known length of a string
literal to directly create a string view of the correct size and pass
this on to the constructor.
By replacing the legacy constructors with the new constructor this is
made the default behaviour.
Calendar fuzzer test too many operations and cause timeout
which does not suerface the real issue. Limit the test data size to 100
instead of 1000 instead.
