Printing a module as Objective-C turns out to be a fantastic way to
verify the (de-)serialization of foreign error conventions, so
collapse the parsing-driving Objective-C printing test of throwing
methods into the general test for methods.
Swift SVN r27880
Printing a module as Objective-C turns out to be a fantastic way to
verify the (de-)serialization of foreign error conventions, so
collapse the parsing-driving Objective-C printing test of throwing
methods into the general test for methods.
Swift SVN r27870
We have an SPI between the Swift compiler and Foundation based on the
SWIFT_SDK_OVERLAY_FOUNDATION_EPOCH preprocessor macro that allows us to
request the new API. rdar://20270080 tracks removing it.
Swift SVN r26475
Swift's Dictionary and Set require their key and element type,
respectively, to be a Hashable type. When importing and bridging an
unspecialized NSDictionary or NSSet, we use 'NSObject' to ensure that
we have type that we know conforms to Hashable. Extend that logic to
specialized NSDictionary and NSSet imports, so that, e.g.,
NSDictionary<id<NSCopying>, V> gets imported as Dictionary<NSObject,
V> rather than the semantically-invalid Dictionary<NSCopying, V>.
Also, when importing a type that refers to an Objective-C type
parameter, don't introduce a typedef for the type parameter: just look
through it to the bound for now.
Swift SVN r24900
Rely on Foundation to provide NS_ARRAY/NS_DICTIONARY/NS_SET macros
that expand to either an unspecialized type (e.g., NSArray *) or a
specialized one (e.g., NSArray<T> *) as appropriate for the definition
of NSArray. Use these macros in the Objective-C printer.
The actual names and form of these macros is still to be debated, but
it's important to be able to handle both Clangs and Foundations with
and without parameterized NSArray/NSDictionary/NSSet.
Swift SVN r24198
When importing a specialized type for an Objective-C collection (e.g.,
NSArray<NSString *> *) that is being bridged to a Swift collection,
produce a more specialized Swift collection type (e.g., [String]) that
we would for the unspecialized type ([NSObject]).
The CMake and lit hackery is here because we need to be able to build
against versions of Clang that both do and do not have Objective-C
generics.
Swift SVN r24196
