We don't do this quite as well as we could (we don't list the storage
type in the @property), but previously we just failed on these types.
<rdar://problem/16992990>
Swift SVN r18528
Importing a header with -import-objc-header causes the Clang importer to
provide an extra module to represent the header's content, and this was
showing up as "@import __ObjC;" in the /generated/ header for the target.
We should just not print anything there and let users import what's
necessary.
<rdar://problem/16917113>
Swift SVN r18081
When generating a header for the Swift half of a mixed-source framework,
we can't import the framework using @import, because that means a submodule
is trying to import a parent module before the module is done being built.
This currently isn't supported in Clang, though it only recently became an
error instead of being ignored.
Instead, we now assume that the framework will have an umbrella header with
the same name as the framework module, which is the same assumption Xcode
makes when you don't provide your own module map. I'm not too concerned about
people trying to build mixed-source frameworks who /don't/ have umbrella
headers.
This doesn't affect app targets at all, which use -import-objc-header instead
of a standalone underlying module.
<rdar://problem/16879704>
Swift SVN r17984
Also add NSZone, which we special-case in the importer but forgot to do in
Sema and PrintAsObjC. (Sorry for the combined commit.)
<rdar://problem/16505708>
Swift SVN r17576
Also, use "#include <objc/NSObject.h>" instead of "@import ObjectiveC;"
to get access to BOOL, SEL, NSObject, and NSString.
This allows generated headers to be used in Objective-C++ contexts, where
modules don't yet work. The dependencies will unfortunately need to be
imported separately (because there's not a direct mapping from module name
back to header file), but that's still better than just being incompatible.
<rdar://problem/16796627>
Swift SVN r17272
NFC. DeclRange is a range over DeclIterators, and is used rather than
ArrayRef<Decl*> to retrieve the members of a nominal type declaration
or extension thereof. The intent is to change the representation of
DeclRange next.
Swift SVN r16571
Introduce CtorInitializerKind to describe the kind of an enum, rather
than a bool, to make way for more initializer kinds in the future.
Swift SVN r16525
This commit adds infrastructure for conversion and testing it.
The conversion is still incomplete, pending discussion about which tags should
we use in the XML documents. I copied the RelaxNG schema from Clang, and will
edit it accordingly.
Swift SVN r16451
Formatting names into strings repeatedly, and using those for semantic
analysis, is generally considered poor form. Additionally, use the
camelCase utilities to perform the string manipulation we need, and
cache results on the ObjCAttr so we don't repeatedly do string
manipulation.
Swift SVN r16334
These bits are orthogonal to each other, so combine them into one, and diagnose attempts to produce a type that's both. Spot-fix a bunch of places this revealed by inspection that we would have crashed in SILGen or IRGen if blocks were be handled.
Swift SVN r16088
This makes sure that Clang uses the mangled class names for
Swift-defined classes. Should be last compiler-side piece of
<rdar://problem/15506580>.
Swift SVN r15977
Language features like erasing concrete metatype
values are also left for the future. Still, baby steps.
The singleton ordinary metatype for existential types
is still potentially useful; we allow it to be written
as P.Protocol.
I've been somewhat cavalier in making code accept
AnyMetatypeType instead of a more specific type, and
it's likely that a number of these places can and
should be more restrictive.
When T is an existential type, parse T.Type as an
ExistentialMetatypeType instead of a MetatypeType.
An existential metatype is the formal type
\exists t:P . (t.Type)
whereas the ordinary metatype is the formal type
(\exists t:P . t).Type
which is singleton. Our inability to express that
difference was leading to an ever-increasing cascade
of hacks where information is shadily passed behind
the scenes in order to make various operations with
static members of protocols work correctly.
This patch takes the first step towards fixing that
by splitting out existential metatypes and giving
them a pointer representation. Eventually, we will
need them to be able to carry protocol witness tables
Swift SVN r15716
With this in place, remove the hacks that peeked at the imported Clang
node to determine the selector for a method. We're all
attribute-driven now. Part of <rdar://problem/16019773>.
Swift SVN r15663
...instead of building our own from the argument patterns. This is all likely
to change soon, so let's not keep a separate implementation in PrintAsObjC.
In that vein, print subscript accessors the same way as any other methods.
No functionality change, except that subscript setter arguments are not all
called "value" any more.
Swift SVN r15532
of those to Class)
I would not call this a regression because the fix is very simple -- just mark
the class @objc, but in return the user will get concrete types on the
Objective-C side, which is a significant benefit.
Swift SVN r15234
This is the same as the previous commit, but for protocols. To do this I
had to modify the ObjC printer to include a SWIFT_PROTOCOL annotation like
the SWIFT_CLASS annotation already in use. This is probably a good thing
anyway.
Second half of <rdar://problem/16296027>
Swift SVN r14985
This means more duplication, but it's also more future-proof: the set of
features used is based on the compiler that generates the header, not the
compiler that eventually consumes the header. To allow for forward-
compatibility, all the macros used by the header can be overridden by the
consuming environment, and the header <swift/objc-prologue.h> will be
included if it exists.
Swift SVN r14893
...when the optional object type is a class or Objective-C protocol type.
This is currently hidden behind -enable-objc-optional because I didn't test
if the generated code is actually correct.
Also add PrintAsObjC support for these.
Known missing pieces: blocks, and Swift structs bridged to Objective-C classes
(right now, just String).
Swift SVN r14416
This is using the compatibility macro SWIFT_CLASS, so older Clangs can still
parse a generated header on its own. This will only be interesting in a
mixed-source target, where we may need to merge a forward declaration with
a Swift-generated @interface. (See <rdar://problem/16076729>.)
Swift SVN r14411
This is a bit ironic considering we're importing NSUInteger as Int rather
than UInt, but Swift should never be using the headers it prints anyway.
Swift SVN r14088
