These APIs are from the Swift 1.2 => Swift 2.0 transition, and are not
relevant anymore.
Removing them reduces the surface area of the library that needs to be
reviewed.
This commit removes _UnsafePartiallyInitializedContiguousArrayBuffer from two
more methods. I did not measure the performance impact of this change but I am
expecting this code to run faster.
This commit simplifies map() of collections into a simple append-loop. The Swift
optimizer can do a better job optimizing code without unsafe constructs. This
change accelerates the MapReduce benchmark by 2x.
The C++ ABI for static locals is a bit heavy compared to dispatch_once; doing this saves more than 1KB in runtime code size. Dispatch_once/call_once is also more likely to be hot because it's also used by Swift and ObjC code.
Alas, llvm::get_execution_seed() from llvm/ADT/Hashing.h still inflicts one static local initialization on us we can't override (without forking Hashing.h, anyway).
These functions are usually lowered away, but can remain if SIL optimizations run but not llvm optimizations.
This is only a workaround. I hope that I can remove the functions soon when we have a better support for buffers in SIL.
This allows removal of the DebugDescription protocol which is invalid
because no classes actually conform to it. The problem is that we need
to send a debugDescription message to an NSObject without loading
Foundation. This is exactly what shims are for. A very simple shim
solves the problem.
Adding a conformance to Foundation doesn't work because NSString can
be used without loading Foundation. debugDescription is one example of
this.
The only value we derive from the _CocoaStringType is its name, which
makes some APIs more readable. Adding a type safe wrapper around it
serves no purpose since we're almost always immediately casting back
and forth from an 'id'. This was previously done with unsafeBitCast,
which should be avoided unless we really need to reinterpret a bit
pattern.
This reflects the fact that the attribute's only for compiler-internal use, and isn't really equivalent to C's asm attribute, since it doesn't change the calling convention to be C-compatible.
Getting the name of a type seems like reasonable core runtime functionality, and something the runtime can cache on its side too. Have the function return a pointer to a raw string in memory owned by the runtime, and have it be wrappen in a Swift.String on the standard library side.
Swift was failing to autolink frameworks in the new text-based SDKs.
Clang r253060 fixes the underlying issue, so we can go back to relying
on autolinking for these.
This reverts the following commits (newest to oldest):
f65884159092a37ea9d54e52ef22
rdar://problem/23511008
Background: Clang has a set of base headers distributed with the compiler
that contain things like vector operations, stddef.h, and tgmath.h.
Swift also needs these headers in order to import C and Objective-C (not
really a surprise), so we symlink to them from lib/swift/clang/. When we
build installable packages, we actually copy them in.
Now the tricky part. Clang's headers are actually at a path like
"include/clang/3.6.0/include/tgmath.h". That "3.6.0" is the Clang version,
which allows multiple Clangs to be installed on a single system. Swift
currently links to the top-level directory, but of course it's only
guaranteed to work with a specific version of the Clang headers. So the
version number here is always the version of Clang we use to build Swift.
Rather than leave the (relatively meaningless) version number here, just
make the symlink point at the "3.6.0" directory rather than the "clang"
directory. This means Swift doesn't have to think about the version number
here at all.
rdar://problem/23223066
