...and use #pragma clang diagnostic when otherwise unavoidable.
As part of this change, start testing generated headers under
-Weverything -Werror, with targeted exceptions.
rdar://problem/18332948
Swift SVN r22010
While Foundation actually defines the NSZone typedef and what you can do with
it, the ObjectiveC module makes use of it in its raw form: "struct _NSZone *".
To avoid a circular dependency, sink our adapter down to the ObjectiveC
overlay.
Swift SVN r21827
This reduces the chances of conflict among inner class names. It's too easy
for a class to be implicitly marked @objc in Swift.
To make this work, correctly preserve the implicitness of @objc through
serialization. (We were probably intending to do this all along, since we
were serializing the flag but not doing anything with it at the other end.)
Swift SVN r21678
There are still problems with nested classes:
- They're much more likely to have colliding compile-time names
(since the outer class's name is dropped).
- They're only picked up if the outer class is also @objc.
But at least now we won't generate invalid Objective-C. Unless the inner
classes have the same name.
rdar://problem/18187877
Swift SVN r21677
ownership attributes by bracketting
header with specific group warning pragma clang.
This patch also requires patch for rdar://17845264
which is currently in TOT. This is //rdar://17023083
Swift SVN r20767
"...because the generated header for a framework is part of the framework's
public Objective-C interface, only declarations marked public appear in the
generated header for a Swift framework."
Just missed a case here when we decided to do things this way.
<rdar://problem/17796727>
Swift SVN r20653
To do this, we keep track of decls with superfluous typedefs (rather than
just the typedefs), and check for that. Tag decls without typedefs are
printed with the tag.
<rdar://problem/17569385>
Swift SVN r20221
weak => 'weak', unless the type is a CF type. I'm not sure weak references to
CF types work anyway, but until we have that cleared up this works.
unowned => 'assign'. In Objective-C, use of 'assign' for object properties is
largely deprecated in favor of 'unsafe_unretained', but unowned
properties behave more like a 'safe_unretained'. Since they don't
auto-update like 'weak', though, this should hint to clients to
be careful about lifetimes.
unowned(unsafe) => 'unsafe_unretained'
As before, Arrays, Dictionaries, and Strings are considered 'copy' properties;
blocks are now considered 'copy' properties as well.
All other types get their (implied) default: 'strong' for objects, 'assign'
for primitives.
<rdar://problem/17346846>
Swift SVN r20112
Also, fix a bug where value properties weren't getting marked as "copy"
if wrapped in IUOs, and replace some identifier-based comparisons with
pointer comparisons against ASTContext-cached decls.
<rdar://problem/17007235>
Swift SVN r19874
attribute is a "modifier" of a decl, not an "attribute" and thus shouldn't
be spelt with an @ sign. Teach the parser to parse "@foo" but reject it with
a nice diagnostic and a fixit if "foo" is a decl modifier.
Move 'dynamic' over to this (since it simplifies some code), and switch the
@optional and @required attributes to be declmodifiers (eliminating their @'s).
Swift SVN r19787
The upshot of this is that internal decls in an app target will be in the
generated header but internal decls in a framework target will not. This
is important since the generated header is part of a framework's public
interface. Users always have the option to add members via category to an
internal framework type they need to use from Objective-C, or to write the
@interface themselves if the entire type is missing. Only internal protocols
are left out by this.
The presence of the bridging header isn't a /perfect/ way to decide this,
but it's close enough. In an app target without a bridging header, it's
unlikely that there will be ObjC sources depending on the generated header.
Swift SVN r19763
You can still mark them @objc explicitly (or @IBOutlet, or anything else that
would require ObjC interop).
Also, don't print private decls in the generated header, whether @objc or not.
not.
Swift SVN r19733
- Category names weren't unique.
- We were using an attribute to detect if something was a Swift category,
but attributes can't be used on categories.
- The test that this was all working was failing in a way that wasn't caught.
To solve these problems:
- We're using a macro to generate category names based on __LINE__ in addition
to the current module.
- The importer uses the macro to detect that the category comes from Swift
(no attribute needed).
- The test now has a deliberate error for -verify to catch.
<rdar://problem/17342287&17538553>
Swift SVN r19479
Because extensions don't have any identity we can check against, we can't
tell when we see an Objective-C category if it came from a Swift extension.
Change PrintAsObjC to mark all such categories with SWIFT_EXTENSION, and
just skip them unilaterally when importing Objective-C code.
Also, actually give Swift extensions a name when writing them as Objective-C
categories. Previously, they were nameless categories ("class extensions"),
but methods in a class extension are supposed to be implemented in the class's
main @implementation, so people were getting unexpected warnings about missing
implementations.
<rdar://problem/17342287>
Swift SVN r19116
.../if/ the protocol and the class are from the same top-level Clang module.
If not, the protocol is /not/ renamed, and users will have to disambiguate
with module qualification.
This kills our hardcoded "RenamedProtocols" list; it turns out this pattern
is more common than we thought /and/ leads to cross-referencing issues.
<rdar://problem/16206627>
Swift SVN r18809
...and just outright import the bridging header if that's what's needed.
This means we'll use @class and @protocol whenever we're just using a class
or protocol in a type, but still import the enclosing module when we need
the definition. We'll also fall back to the module (or bridging header) if
we need something /else/ from C: a struct, a typedef, whatever.
<rdar://problem/17183425>
Swift SVN r18795
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
