+ (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
Have them fill out a vector provided by the caller instead.
It is very easy to have callers just go through the array, thus wasting memory, as
the clang importer ended up doing.
The caller should be the one deciding if the array must be copied in ASTContext or not.
Swift SVN r23472
This functionality doesn’t really change what we accept right now, because we eagerly import all of the methods of a class when we do *any* kind of lookup into the class. However, when we manage to stop doing that, this operation will become more important.
Swift SVN r23289
The ClangDiagnosticConsumer forwards diagnostics from Clang's diagnostic machinery
to Swift's. It deliberately filters out things that happen in our top-level dummy
buffer (usually trivial things like "module imported here"). Unfortunately, it was
doing so by checking against the current SourceManager's "main file". When building
Clang modules (compiling PCM files), we're dealing with a new SourceManager, whose
main file is the module map file.
Instead, just check against the (very unlikely) name of our dummy input file,
like we do for imported headers.
rdar://problem/18867749
Swift SVN r23121
llvm::Optional lives in "llvm/ADT/Optional.h". Like Clang, we can get
Optional in the 'swift' namespace by including "swift/Basic/LLVM.h".
We're now fully switched over to llvm::Optional!
Swift SVN r22477
FixNum.h and BCRecordLayout.h will move down into LLVM, APINotes
will move into Clang. Get the namespaces right before we start to move
files around.
Swift SVN r22218
Removes the initWithBool: hack from the Clang importer. We can now
express NSNumber's conformance to the BooleanLiteralConvertible
protocol in the overlay.
Swift SVN r21976
Conforming to BooleanLiteralConvertible now requires
init(booleanLiteral: Bool)
rather than
static func convertFromBooleanLiteral(value: Bool) -> Self
This posed a problem for NSNumber's conformance to
BooleanLiteralConvertible. A class needs a required initializer to
satisfy an initializer requirement, but one cannot add a required
initializer via an extension. To that end, we hack the Clang importer
to import NSNumber's initWithBool with the name
init(booleanLiteral:)
and add back the expected init(bool:) initializer in the
overlay. These tricks make NSNumber even harder to subclass, but we
don't really care: it's nearly impossible to do well anyway, and is
generally a Bad Idea.
Part of rdar://problem/18154091.
Swift SVN r21961
This re-applies r21857, which was reverted r21871, fixing a use-of-
uninitialized-memory error that only showed up in optimized builds.
Swift SVN r21933
