<rdar://problem/20855539> Add SCNVector3/4 Swift convenience
<rdar://problem/20854576> Add SCNFloat to the SceneKit swift overlay
Patch by Amaury Balliet.
Swift SVN r30353
There is no reason for the compiler to be synthesizing a body of
_domain when it can be implemented in a protocol extension. As part of
this, fix a recent regression in the computed domain: it was using
string interpolation, which means that the recent changes not to print
qualified names affected the domain of the generated NSErrors. Oops.
Swift SVN r30343
In iOS 9 and OS X 10.11 the old GameKit was effectively renamed GameCenter, while
the new GameKit is a sort of umbrella framework like Cocoa. We need to support
backwards deployment, though, so the GameCenter overlay links to GameKit.framework.
(This is essentially the same solution implemented for CoreImage moving out of
QuartzCore in r28449)
rdar://problem/21340738
Swift SVN r30322
This is a low-level API that bypasses the usual type checks. To avoid
misuse, we add a dynamic type check that kicks in when stdlib asserts
are enabled.
Swift SVN r30311
This patch implements the pre-specialization for the most popular generic types from the standard library. If there are invocations of generic functions from the standard library in the user-code and the compiler can find the specialized, optimized versions of these functions, then calls of generic functions are simply replaced by the calls of the specialized functions.
This feature is supposed to be used with -Onone to produce much faster (e.g. 5x-10x faster) executables in debug builds without impacting the compile time. In fact, the compile-time is even improved, because IRGen has less work to do. The feature can be considered a light-weight version of the -Odebug, because pre-specialization is limited in scope, but does not have a potentially negative compile-time impact compared to -Odebug. It is planned to enable it by default in the future.
This feature is disabled by default for the time being. It can be enabled by using a hidden flag: -Xllvm -use-prespecialized.
The implementation consists of two logical steps:
- When the standard library is being built, we force a creation of specializations for the most popular generic types from the stdlib, e.g. Arrays of integer and floating point types, Range<Int>, etc. The list of specializations is not fixed and can be easily altered by editing the Prespecialized.swift file, which is responsible for forcing the specialization of generic types (this is simple solution for now, until we have a proper annotation to indicate which specializations of a given generic type or function we want to generate by means of the pre-specialization). These specializations are then optimized and preserved in the stdlib dylib and in the Swift SIL module. The size increase of the stdlib due to creation of pre-specializations is currently about 3%-7%.
- When a user-code is being compiled with -Onone, the compiler would run a generic specializer over the user-code. If there are calls of generic functions from the standard library, the specializer would check if there is an existing specialization matching these invocations. If such a specialization is found, the original call is replaced by the call of this more efficient specialized version.
Swift SVN r30309
Due to the fact that AnyClass is not Hashable, and that currently
NSKeyedArchiver/Unarchiver work with NSObject-derived, NSCoding
compliant classes, we are marking the decodeObjectOfClasses API refined
for Swift in our objc header and providing the desired overlay in our
overlay as shown below.
Arrays were also considered (for both API), but the underlying
implementation is entirely set-based, and using Arrays in Swift vs Sets
in objective C felt like too far a deviation.
Patch by Michael LeHew Jr.
Changes to the Dictionary test are caused by bumping the Fonudation API
epoch and taking in a fix in the types used in an NSDictionary
initializer.
rdar://21486551
Swift SVN r30297
The big one, though, is the use of 'lazy' in _masterThreadOneTrial.
Removing it takes the function from 62s to 2s on my machine.
That's rdar://problem/20875936.
Swift SVN r30292
Class representation
As Joe explained, when Swift passes a metatype like AnyClass for an type
defined in Objective-C, it will pass the Swift metadata pointer instead
of an id-compatible Class.
Swift SVN r30268
Full type metadata isn't necessary to calculate the runtime layout of a dependent struct or enum; we only need the non-function data from the value witness table (size, alignment, extra inhabitant count, and POD/BT/etc. flags). This can be generated more efficiently than the type metadata for many types--if we know a specific instantiation is fixed-layout, we can regenerate the layout information, or if we know the type has the same layout as another well-known type, we can get the layout from a common value witness table. This breaks a deadlock in most (but not all) cases where a value type is recursive using classes or fixed-layout indirected structs like UnsafePointer. rdar://problem/19898165
This time, factor out the ObjC-dependent parts of the tests so they only run with ObjC interop.
Swift SVN r30266
Full type metadata isn't necessary to calculate the runtime layout of a dependent struct or enum; we only need the non-function data from the value witness table (size, alignment, extra inhabitant count, and POD/BT/etc. flags). This can be generated more efficiently than the type metadata for many types--if we know a specific instantiation is fixed-layout, we can regenerate the layout information, or if we know the type has the same layout as another well-known type, we can get the layout from a common value witness table. This breaks a deadlock in most (but not all) cases where a value type is recursive using classes or fixed-layout indirected structs like UnsafePointer. rdar://problem/19898165
Swift SVN r30243
AppKit links CoreData and this relationship isn't expressed
in the build mechanics for the overlays, which can cause
link failures when building the overlay.
rdar://problem/21837604
Swift SVN r30223
