Use the generic type lowering algorithm described in
"docs/CallingConvention.rst#physical-lowering" to map from IRGen's explosion
type to the type expected by the ABI.
Change IRGen to use the swift calling convention (swiftcc) for native swift
functions.
Use the 'swiftself' attribute on self parameters and for closures contexts.
Use the 'swifterror' parameter for swift error parameters.
Change functions in the runtime that are called as native swift functions to use
the swift calling convention.
rdar://19978563
If the Swift error wrapped in a _SwiftNativeNSError box conforms to
Hashable, the box now uses the Swift's conformance to Hashable.
Part of rdar://problem/27574348.
This is a purely mechanical change replacing the attributes with the reserved
spelling. Compilers are to not error when they encounter a reserved spelling
for an attribute which they do not support.
...and explicitly mark symbols we export, either for use by executables or for runtime-stdlib interaction. Until the stdlib supports resilience we have to allow programs to link to these SPI symbols.
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.
This will let us eventually do tagged pointer optimization for small error values. We don't take advantage of this in IRGen yet, but we can take advantage of it in the dynamic cast code in a few places, so it gets exercised, and doing this now will let us backward-deploy the optimization when we do implement it in the future.
Un-revert the below commits with the following addition:
add declarations for posix_spawn related APIs to SwiftPrivateDarwinExtras.
posix_spawn-related APIs aren't available in the public SDKs, so force past
the availability by creating our own stubs in the internal DarwinExtras
library.
r31244, r31245
CMake: build all platforms except watchOS using the public SDK
Covers rdar://problem/21145996.
A step towards rdar://problem/21099318.
Switch SDK overlays to use the public SDK
I had to cut the dependency on CrashReporterClient.h and reimplement
some of that code inline in the Swift runtime. This shoud be OK (even
though not very clean), since the layout of CrashReporter sections is
ABI.
rdar://21099318
Swift SVN r31252
This reverts commit cd3f1ba7d1ee2397817e1a165209fdeab8a1c004.
Reverting this b/c it is breaking buildbots with the following:
CMake Error at CMakeLists.txt:522 (message):
CrashReporterClient library is required, but it was not found
Swift SVN r31047
If we see an ErrorType-conforming value type while casting to NSError, do the coercion in the runtime, so that e.g. 'error as Any as! NSError' works as well as 'error as NSError'.
Unfortunately, we can't do this for ErrorType-conforming classes without shattering SIL's brittle view of the world due to rdar://problem/20507075. Casts between class types are fairly deeply assumed not to change the identity of the reference.
Swift SVN r27225
Some future-proofing to let us change ErrorType's reference counting in the future, or to use various tagged pointer optimizations in its representation.
Swift SVN r27213
We may want to use optimized ErrorType representations that don't naturally "become" NSErrors, such as tagged-pointer representations of small error enums, or a tagged function pointer to a deferred error type constructor. Rename the runtime function to something a bit more descriptive of its real purpose, not its implementation.
Swift SVN r27209
Atomically initialize and load the NSError bridging fields within an ErrorType box so that we do the right thing when two threads concurrently coerce the box to NSError.
Swift SVN r26996
If the NSError part of the box hasn't been initialized yet, fill it in with the domain and code of the contained value. This will allow us to efficiently turn ErrorType values into NSErrors, either for bridging or for coercion purposes.
Swift SVN r26958
This allows ErrorTypes referencing Cocoa NSErrors to be pattern-matched against our bridged enums, at least dynamically. (The compiler still doesn't understand these bridging conversions yet.)
Swift SVN r26839
After some more discussion with John, we decided that subclassing is the only realistic option, at least until we eventually are able to integrate with the OS. Switch things around to allocate Swift error boxes as an ObjC subclass that contains the error value instead of trying to game it as a CFError.
Swift SVN r26562
Teach ExistentialTypeMetadata how to project out the value pointer, type metadata, and protocol witness table from ErrorType containers. NFC yet; the dynamic casting and reflection machinery needs further work to correctly handle ErrorType boxes.
Swift SVN r26509
