- use @_effects(releasenone) to solemnly swear to the compiler that we won't release anything inside these getters, eliminating refcounting to call them
- micro-optimize identifierDoesNotRequireSpecialCaseHandling, allowing us to delete the cache of it without regressing perf
On the test app this goes from "so slow I didn't bother to see how long it takes to finish" to "finishes in around 1 second"
Resolves 137885111
Co-authored-by: David (Swift) Smith <david_smith@apple.com>
* Provide public access for some internal functions, to enable swift-corelibs-foundation
* Add access to TimeZone internals for swift-corelibs-foundation
* Fix default TimeZone for Linux
* Remove unneeded private entry point
* Do not use a recursive definition of description for String.Encoding
* Merge in some WASI changes and other Data fixes
* Add temporary initializer to the stub URL
* Remove Hashable conformance for CocoaError. This allows userInfo to be Any instead of AnyHashable
* Remove some protocols which depend on NSError from swift-foundation -- they will live in swift-corelibs-foundation
* Adjust the debug description of the GMT ICU calendar to be a little less implementation-specific
* Use an English-only description for string encodings, for compatibility with existing SCL-F clients
* Use a more compatible definition of a backstop value for Bundle
CalendarGregorian currently decomposes `Locale` into its identifer plus preferences, stores the two properties separately, and recreates everytime a `Locale` when needed. This results in us always creating new locales, and calling ICU whenever requesting its properties. While we do have cache in place for `Locale.init(identifier:preferences:)` for nil `preferences`, we are not hitting the cache because `preferences` is always non-nil when calendar is `.current`.
Fix this by storing a `Locale` inside calendar so we always hit the cache. This also allows `Locale.autoupdatingCurrent` to work properly -- previously you would not get the right locale back if you set `calendar.locale = Locale.autoupdatingCurrent`. This change fixes that as the identity of the `Locale` is now preserved.
Resolves 125169335
"First day of week" and "minimum days in first week" are locale specific. Move the logic of fetching the locale's preferred value into `LocaleProtocol`, so that calendar can return the value from its enclosed locale.
Resolves 123630636
Calendar's weekend support requires the following functions:
1. `isDateInWeekend`: answers whether a given date is in weekend
2. `weekendRange`: function that returns the days and times of the weekend
This implements the first. The second one, weekend range, is in fact related to calendar's locale rather than calendar itself. Move it over to `_LocaleProtocol` and have locale handle it.
