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.
1. The flatten plugin appended the relative module paths to the URLs in <scm>.
The same kind of problem solved earlier with ${proj.url}, and fixed the same way.
I was unable to find any way to tell the plugin to not do that append, even after
reading some of the plugin code.
2. The stylesheet containing the JCite styles was not copied in the generated javadoc.
The first part of our custom stylesheet is 100% the same as the oficial one.
So the only part that was visually affected was the code produced by JCite.
The code still used <pre> and <code>, so it was monospaced and well indented / wrapped,
but no syntax colors.
