this is just to be compatible with the current transcoders and can be
undone when the transcoders (based on ForwardParser/ReverseParser) are
improved too.
Add inlinability annotations to restore performance parity with 4.2 String.
Take advantage of known NFC as a fast-path for comparison, and
overhaul comparison dispatch.
RRC improvements and optmizations.
* Refactor out RRC implementation into dedicated file.
* Change our `_invariantCheck` pattern to generate efficient code in
asserts builds and make the optimizer job's easier.
* Drop a few Bidi shims we no longer need.
* Restore View decls to String, workaround no longer needed
* Cleaner unicode helper facilities
This is a giant squashing of a lot of individual changes prototyping a
switch of String in Swift 5 to be natively encoded as UTF-8. It
includes what's necessary for a functional prototype, dropping some
history, but still leaves plenty of history available for future
commits.
My apologies to anyone trying to do code archeology between this
commit and the one prior. This was the lesser of evils.
- Uses version 61.1 from ICU Github unicode-org/icu repository.
- Updates mixin_linux_installation to add libicu option.
- Use -j when building libicu.
- When buiding ICU, use --with-library-suffix=swift
This suffixes the ICU symbols with _swift.
The libaries are now named libicuucswift, libicui18nswift
and libicudataswift.
- Add the contents of uconfig.h.prepend into uconfig.h. This avoids
passing the renaming CFLAGS to swift and swift-corelibs-foundation.
Also resolves:
SR-5618: libicu compilation should happen in parallel respecting -j.
The code to compare character values can be huge; it doesn’t seem a good idea to forcibly inline it. The @inline(__always) here can make specialized Set<Character> operations balloon 10x their current size with unrelated modifications in Set.
The code size bloat doesn’t always happen; I *guess* that _fastPaths inside String.== cause unintuitive inlining decisions in callers.
- Make internal (but @inlinable)
- Limit API to what is actually supported: a single boolean value.
- Rename members:
init(native:,bits:) ⟹ init(native:,isFlagged:)
func isNativeWithClearedSpareBits() ⟹ isUnflaggedNative
var nativeInstance_noSpareBits ⟹ unflaggedNativeInstance
func isUniquelyReferenced_native_noSpareBits() ⟹ isUniquelyReferencedUnflaggedNative()
When I added support for importing long double as Float80 on Intel, I neglected to conform it to CVarArgs. This patch fixes that, which most importantly lets users use String(format:) with Float80 values.
The key thing here is that all of the underlying code is exactly the same. I
purposely did not debride anything. This is to ensure that I am not touching too
much and increasing the probability of weird errors from occurring. Thus the
exact same code should be executed... just the routing changed.
_BridgeObject turned out not to be a great choice, because it doesn’t support tagged values on 32-bit platforms. Extracting the offset from index storage is a good idea anyway!
- __SwiftNativeNSArrayWithContiguousStorage.withUnsafeBufferOfObjects
- __ContiguousArrayStorageBase._getNonVerbatimBridgingBuffer()
- __ContiguousArrayStorageBase._getNonVerbatimBridgedCount()
- Most __SwiftDeferredNSArray members
- HeapBuffer was at the wrong abstraction level, for no good reason. We have ManagedBuffer for the general case; we don’t need a slightly less general variant of it.
- Current usages of HeapBuffer are hyper specific: they all are flat buffers of AnyObjects, facilitating bridging. It makes sense to dedicate _HeapBuffer for this single usecase.
- Introduce a dedicate ManagedBuffer subclass for bridging buffers. This will make it slightly easier to recognize these in heap dumps.
- Inlinability audit.
