Previously if someone changed one of the mock SDK headers, it might not get
picked up by the PrintAsObjC tests because it treats those headers as
system headers. Swift doesn't have this problem because it always uses the
-fmodules-validate-system-headers option, but we should pass it explicitly
to Clang here for those not using clean builds / clean module caches.
Swift SVN r22982
This change adds infrastructure to represent inline markup in the AST,
implements parsing of some of the inline markup (*emphasis*, **strong
emphasis**, `interpreted text`, ``inline literal``), and XML generation
for these constructs for SourceKit clients to consume.
The parsing itself is incomplete for constructs not mentioned above.
Most notably, we don't parse hyperlinks, and we don't parse the
double-colon that changes the next paragraph into a literal block.
Swift SVN r22752
...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
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
A while back we decided to require @IBOutlets to be optional (via ! or
?); we got as far as ripping out the implicit !'ification of
@IBOutlets, but never added the diagnostic. Diagnose this restriction
with Fix-Its.
Swift SVN r19981
This only tackles the protocol case (<rdar://problem/17510790>); it
does not yet generalize to an arbitrary "class" requirement on either
existentials or generics.
Swift SVN r19896
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
CGFloat is 32-bit on 32-bit architectures and 64-bit on 64-bit
architectures for historical reasons. Rather than having it alias
either Float (32-bit) or Double (64-bit), introduce a distinct struct
type for CGFloat. CGFloat provides a complete set of comparisons and
arithmetic operators (including tgmath functions), initializers allows
explicit conversion between it an Int, UInt, Float, and Double, as
well as conforming to all of the protocols that Float/Double do.
This formulation of CGFloat makes use of CGFloat
architecture-independent, although it still requires a number of casts.
Fixes <rdar://problem/17224725>
Swift SVN r19689
- 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
prevents synthesized stuff from being reflected back to the runtime, and prevents
PrintAsObjC from reflecting it into the generated ObjC header.
This fixes:
<rdar://problem/17165953> Swift: @lazy property reflects back into Objective-C with two properties, one for underlying storage
which caused us to print a decl for a lazy property's storage, which is useless
but also syntactically incorrect, causing clang to fail to parse the header.
Swift SVN r19054
...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
