* Updated era data format in supplementalData.
* Include tentative era names in data. Implemented Japanese era loaded from CLDR data in ICU4J.
* ICU4C implementation, ICU4C refactoring. WIP.
* VS project updates and some bug fixes
Also added API comments.
* Review feedback and bug fixes
- NULL to nullptr
- use of LocalUResourceBundlePointer
- TYPO "name" to "named"
- env var checking stricmp() == 0
* API comment correction based on feedback
* Duplicate the comment in ucal.h to calendar.h
* Fixed spelling errors in API comment
Currently U_FALLTHROUGH is not defined for GCC, meaning that any switch case statements with fall-throughs will generate warnings when building ICU4C.
In GCC 7, they added support for: "_attribute_((fallthrough))" which we can now use for U_FALLTHROUGH, which eliminates many warnings when building with GCC.
Enable the Windows UWP version of ICU4C to use TZ update/override files (.res files) for out-of-band timezone data updates. Also use the *W version of the Windows APIs to avoid code-page conversion.
* ICU-20098 Fix the validty check for extlang in uloc_forLanguageTag
BCP 47 has the following for language. extlang subtag can only be
preceded by 2*3ALPHA. Add a check for the length of language subtag
before extlang subtag.
language = 2*3ALPHA ; shortest ISO 639 code
["-" extlang] ; sometimes followed by
; extended language subtags
/ 4ALPHA ; or reserved for future use
/ 5*8ALPHA ; or registered language subtag
extlang = 3ALPHA ; selected ISO 639 codes
*2("-" 3ALPHA) ; permanently reserved}}
With this change, 'hant-cmn-CN' would drop '-cmn-CN' keeping only
'hant'.
* ICU-20098 Fix the validty check for extlang for ICU4J
* ICU-20098 Fix the compiler failure for ICU4J
* ICU-20098 Fix a compile error and test.
* ICU-20098 Add a test for invalid private use singleton
ICU4C's check for private use singleton subtag ('x') is wrong and
treats invalid language tags as valid.
ICU4J's check is correct and does not require any change.
Fix that and add tests to both ICU4C and ICU4J.
ICU does not report Out-Of-Memory (OOM) if it fails to memory map the data file(s) when calling the various platform API(s) to do so.
When you are using ICU with memory-mapped data file(s), and ICU fails to map the data file due to being out-of-memory, it does not bubble this failure up to the API that was called. You will instead get back the error U_MISSING_RESOURCE_ERROR, rather than U_MEMORY_ALLOCATION_ERROR, which might be a bit surprising to the caller of the API. This can lead to the application thinking that there are no resources for "en_US" or "en" (or even "root").
This change modifies ICU4C so that it will report back U_MEMORY_ALLOCATION_ERROR if OOM happens when attempting to load the data files.
By extracting this test case into a separate class and separating the
complex and time consuming building of the UnicodeSet disorderedMarks
data structure into an @BeforeClass shared setup method it becomes
possible to test the 18 different transliteration rules as a
parameterized test case.
This will lower the running time per test case and also aid in debugging
as it will make it immediately obvious which transliteration rules cause
test failures (and which don't).
When running in Android, java.util.TimeZone.getDefault() will only
return a TimeZone object for a time zone that actually exists, so when
passing a bogus test TimeZone object to setDefault() and afterwards
calling getDefault() it won't return that same time zone.
Changing our tests to instead use a real existing (but otherwise unused)
time zone instead makes the tests work in Android as well.
Neither of these tests was testing the ability to set an arbitrarily
made up time zone as the default, so no test coverage is lost.
* ICU-13530 test & fix cptrie.getRange() when small null data block matches the start of a non-null fast data block
* ICU-13530 fix test bug
* ICU-13530 test & fix bug calculating worst-case data array capacity at start of compaction
* ICU-13530 docs: clarify buildImmutable() discards upper bits, trie then returns unsigned ints; range iteration slower than if ranges were stored directly
* ICU-13530 accept feedback on docs
Different implementations of BigDecimal.stripTrailingZeros(), in
different versions of the JDK (and different versions of Android), have
differences in their handling of zero. To avoid this, ICU4J can return
BigDecimal.ZERO for any value that is equal to zero, instead of calling
BigDecimal.stripTrailingZeros() in this problematic case.
