...when importing NSUInteger. Stop pretending it means anything else.
No functionality change; groundwork for rdar://problem/19134055.
Swift SVN r31353
Sink the actual logic for omitting needless words way down into
Basic, so we can re-use it elsewhere. Tie the Clang importer into that
logic, mapping Clang types down to strings appropriately. NFC
Swift SVN r31233
Examples:
NSString's
@property (nonatomic, copy) NSString *uppercaseString;
becomes
var uppercase: String { get }
NSColor's
+(NSColor *)redColor;
becomes
class func red() -> NSColor
More heuristics for rdar://problem/22232287.
Swift SVN r31221
The -enable-omit-needless-words option attempts to omit needless words
from method names imported from Clang. Broadly speaking, a word is
needless if it merely restates the type of the corresponding parameter,
using reverse camel-case matching of the type name to the
function/parameter name. The word "With" is also considered needless
if whether follows it is needless, e.g.,
func copyWithZone(zone: NSZone)
gets reduced to
func copy(zone: NSZone)
because "Zone" merely restates type information and the remaining,
trailing "With" is also needless.
There are some special type naming rules for builtin Objective-C types,
e.g.,
id -> "Object"
SEL -> "Selector"
Block pointer types -> "Block"
as well as some very-Cocoa-specific matching rules, e.g., the type
"IndexSet" matches the name "Indexes" or "Indices".
Expect a lot of churn with these heuristics; this is part of
rdar://problem/22232287.
Swift SVN r31178
Block types can't be used in structs (because they're managed by ARC),
are rarely referred to by pointers, and would pretty much never be
globals. Additionally, their syntax is complicated enough that people
tend to make typedefs for them fairly frequently. We'd like to preserve
that sugar, but we don't really need to preserve the representation
when the most likely use of the block is in a bridged context (e.g. a
method parameter). In the rare case where the representation /is/
important, fall back to re-importing the underlying type.
rdar://problem/22013912
Swift SVN r30738
When adding mirror declaration members to a class, if the protocol has an annotated
availability then apply that availability to the mirror declaration member unless the
protocol member already has its own availability.
rdar://problem/21825141
Swift SVN r30251
This is usually a more helpful type than our alternative, 'NSObject', although
it's not Equatable or Hashable. Since pretty much everything from Objective-C
inherits from NSObject, though, keeping the protocol qualifiers is much more
useful from a type-safety perspective.
The particular benefit for this comes with a change to libdispatch's <os/object.h>:
with dispatch types all declaring that they inherit from NSObjectProtocol, the
canonical form of the imported 'dispatch_queue_t' is now just a simple protocol
reference. That's type-safe as above, but is also a type that can be extended.
rdar://problem/16213421
Swift SVN r30100
These are contexts where we have enough information to bridge /back/
properly; that is, where we can distinguish CBool, ObjCBool, and
DarwinBoolean. In cases where we can't, we keep the three separate;
only CBool is really the same type as Bool.
This also affects current import behavior for ObjCBool, which was previously
incorrectly conflated with CBool in certain cases.
More rdar://problem/19013551
Swift SVN r30051
If there is a method -foo: that's unavailable (for whatever reason), and we now
have a method -foo:error: that we'd like to import, it's okay to drop the error
parameter there. Overload resolution can handle filtering out the unavailable
method.
rdar://problem/21497221
Swift SVN r29746
+ (Foo *)foo:(id)obj error:(NSError **)error NS_SWIFT_NAME(init(object:));
+ (Foo *)foo:(id)obj error:(NSError **)error NS_SWIFT_NAME(init(object:error:));
These are now mapped, respectively, to
init(object: AnyObject) throws
init(object: AnyObject, error: ()) throws
rather than both mapping to the first one and having no way to specify the second.
Swift side of rdar://problem/21091469. Requires Clang commits.
Swift SVN r29534
A method has "__" prepended to its basename; an initializer has "__"
prepended to its first argument.
There are a few holes here involving no-argument initializers and factory
methods, but hopefully we won't need to remap those with swift_private anyway.
More of rdar://problem/20070465
Swift SVN r29429
...including structs and struct fields, enums and enum cases, typedefs,
protocols, classes, and properties.
The main problem is that this /doesn't/ handle top-level /lookup/, so you
can't actually find any of these renamed types. This is fixed in the next
commit.
This does not handle methods, subscripts, or initializers.
Part of rdar://problem/20070465
Swift SVN r29427
If Clang->Swift functions are named "import*" ("importDecl", "importName",
etc.), then clearly Swift->Clang functions should be called "export*".
(Originally we called both directions "import", but recent additions have
used "export" for Swift->Clang instead.)
No functionality change.
Swift SVN r29424
...so that their modern NSError-based variants won't be imported using an
extra "error: ()" parameter. Apart from looking prettier, this avoids a
crash when overriding the "error: ()" versions, rdar://problem/21144509.
Once NS_REFINED_IN_SWIFT has been implemented we can probably use that instead.
Filed rdar://problem/21192039 to remove the hack at that point.
rdar://problem/21177341
Swift SVN r29212
Then use that to ban NSError.init(), because it doesn't create a valid
NSError. In the long run Foundation will hopefully add this to their
headers, but they can't yet (rdar://problem/19977891).
rdar://problem/21042412
Swift SVN r28881
Instead of importing everything and filtering later (so all of clang modules get deserialized and associated Swift decls get created),
lazily import as Swift decls only the Clang decls that we need from a particular header.
This also fixes printing ObjC categories in the header as Swift extensions.
Swift SVN r28358
...so that they can still be used with exhaustive switches.
This is a hack---groveling through the AST to see if it's in the particular
form of an imported enum case alias---but at least it's limited to imported
properties.
More rdar://problem/18662118
Swift SVN r28326
By declaring the parameter's retain count convention, we can avoid the
use of Unmanaged. (See test cases for more examples.)
The last piece of this puzzle is offering a sugared overload with multiple
return values (rdar://problem/20436785) but that will have to wait.
This requires changes to Clang; please update.
rdar://problem/20436757
Swift SVN r28216
The Clang importer was relying on stashing the protocol list within a
nominal type or extension and then retrieving it to fill in all of the
members, which will typically happen before the protocol conformances
can be handled. This prevented the conformance lookup table from being
directly usable for these protocol queries.
In time, the conformance lookup table should have separate callbacks
for "list the protocols to which this conforms" and "provide all of
the conformances", which can make these computations lazier. For now,
use a side table to stash these conformances.
Part of rdar://problem/18448811.
Swift SVN r27980
When -enable-simd-import is active, if we encounter a vector type, try to load the SIMD Swift module, and if successful, map float, double, and int vectors to SIMD.{Float,Double,Int}N types if they exist.
Swift SVN r27367
I don't want to call this complete until
a) we handle using alias names in switch statements (right now they're
straight-up rejected, not just non-complete), and
b) we prefer non-deprecated names over deprecated ones to be the "real"
enum cases.
but this is a good start, and fixes them showing up poorly in the SDK
analyzer.
rdar://problem/18662118
Swift SVN r27130
Stop storing a conformances array on ExtensionDecls. Instead, always use the conformance lookup table to retrieve conformances (which is lazy and supports multi-file, among other benefits).
As part of this, space-optimize ExtensionDecl's handling of conformance loaders. When one registers a conformance loader, it goes into a DenseMap on ASTContext and gets erased once we've loaded that data, so we get two words worth of space back in each ExtensionDecl.
Swift SVN r26353
When an imported Objective-C property has nullability, force that
nullability onto the result of its getter and the parameter of its
setter, so that we have consisteny nullability among the three. SILGen
assumes that this is the case, so this fixes the null_resettable-based
crash in <rdar://problem/20145910>.
Swift SVN r26198
This fixes the import of enums like NSCalendarUnit, which changed from
NSXXXCalendarUnit to NSCalendarUnitXXX, as has been the guideline in
recent years. Now even when the old names are present, we can still
prefix-strip based on the new names. If /all/ options are deprecated,
though, we'll prefix-strip as we did before.
Note that we /don't/ check the current deployment target for this,
because we want to use the "nice" names as soon as we have an SDK where
they're available, not when the deployment target matches such an SDK.
rdar://problem/17686122
Swift SVN r26184
The contract for LazyResolver::loadAllMembers() was that the caller
would handle actually adding the members, since it was an iterable
declaration context and could centralize that (simple) logic. However,
this fails in the Clang importer in rare but amusing ways when some of
the deferred actions (e.g., finishing a protocol conformance) depend
on having the members already set. The deferred action occurs after
the member list is complete in ClangImporter's loadAllMembers(), but
before its caller actual set the member list, leaving incomplete
conformances. Fixes rdar://problem/18884272.
Swift SVN r25630
...even if they were designated in the base class. (Unless they're required,
in which case they're still required.)
This led to Swift subclasses treating convenience initializers as
designated initializers, which (if synthesized) led to properties being
initialized twice.
rdar://problem/19730160
Swift SVN r25410
We certainly can't import them as stored properties, and it's too late to try to bridge them as computed property, so restore the old behavior of importing them as unbridged object types. The types still come in as strong managed reference types, which is still wrong, but seems to be right enough for Khan Academy and potentially other existing apps for now, and I don't want to introduce additional source-breaking changes and instability this late in the game. Fixes rdar://problem/19789023, leaving rdar://problem/19790608 to be done when we can afford more churn.
Swift SVN r25158
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
This has been long in coming. We always had it in IRGenOpts (in string form).
We had the version number in LangOpts for availability purposes. We had to
pass IRGenOpts to the ClangImporter to actually create the right target.
Some of our semantic checks tested the current OS by looking at the "os"
target configuration! And we're about to need to serialize the target for
debugging purposes.
Swift SVN r24468
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
Previously, this storage required that alignof(void *) >= alignof(Decl). This is
true on 64-bit platforms, where these are both 8, but on 32-bit platforms
alignof(void *) is only 4.
This now allocates enough bytes to match the alignment of the Decl in question.
This does mean that a void * must fit in that alignment, but this is true on 32-
and 64-bit platforms, and a static_assert ensures that this is true at compile
time.
As part of this change, the logic for allocating memory for a Decl has been
refactored into a separate function, so that the logic for allocating space for
a ClangNode can be centralized.
Swift SVN r23990
Use the CodeGenOptions the Clang frontend determined for the compiler instance instead of starting from scratch, so that we pick up important settings like '-mstackrealign'. Fixes the GLKit test on iOS. rdar://problem/19180367
Swift SVN r23792
