This adds a fast path for single-code-unit Character
construction. Rather than use the general purpose String based
initializer (which then repeats grapheme breaking to ensure a trap,
amongst other inefficiencies), just make the Character from the single
unicode scalar value directly.
This also speeds up simple iteration of BMP strings when the optimizer
is unable to eliminate the subscript. Around 2x for ASCII, and around
20% for BMP UTF16.
This reverts commit 25985cb764. For now,
we're trying to avoid spurious non-structural changes to the mangling,
so that the /old/ mangling doesn't appear to change. That doesn't mean
no changes at all, but we can save this one for later.
This is done by ensuring that the corresponding Character constructor is inlined. llvm will do the constant folding.
Also add a test which checks this.
It makes character literals much faster (3x improvement for the CharacterLiteralsSmall benchmark)
And it removes _a lot_ of redundant code (~80% for the CharacterLiteralsSmall benchmark)
The COW existential implementation sets the existential box's
new value but fails to set the box's new type. Hijinks ensue
when the new value is later used as if it were of the old type.
rdar://31955457
HeapObject contains an InlineRefCounts. The Swift shim definition of
InlineRefCounts used uint64_t, which has the correct size but the incorrect
alignment on armv7k. This caused the Swift stdlib and the Swift runtime
to disagree about object layouts.
rdar://31664545
I had optimistically written the code here optimistically hoping #7837 would land in time for me to merge, but that didn't happen, so adjust some things to match the current 12-byte object header size on 32-bit, and introduce some ABI constants for the expected 32- and 64-bit object header sizes we can assert against so that we have some robustness when it eventually changes again. Implements rdar://problem/31768303.
Some places in this header were following the LLVM convention of:
namespace ... {
struct Foo {
};
}
and one-two places had extra indentation. I standardized the code on the LLVM
convention.
The underlying type's ordering may not be appropriate for the wrapped
type (think an ordered list whose underlying type is NSString).
Frameworks can always add a Comparable conformance explicitly.
We squeak out of this being a source-breaking change by virtue of
never having released a working version of it. Rintaro fixed the
ambiguity problems back in f11b74176b, but that was after the last
rebranch for Swift 3.1.
rdar://problem/30166538
The "superclass as associated type" modeling was put in to
maintain backward compatibility.
We just bumped the version number because of new mangling so
we may as well fix this sillyness too.
