(including both classes and categories, and also @protocol declarations)
This is a hack in that we use two different mechanisms for importing
bridging header decls now: the manual output of ParseTopLevelDecl, and
the callbacks of a clang::ASTConsumer. We should probably unify these,
but that's a bigger change that isn't as obviously safe.
Also note that we probably aren't getting this right for things included
with -include, which we already don't have a good model for.
This adds test cases for both the module and bridging header cases,
although the former worked correctly already.
rdar://problem/24806068
At some point I want to propose a revised model for exports, but for now
just mark that support for '@exported' is still experimental and subject
to change. (Thanks, Max.)
...depending on where the typedef is defined. Removing this inconsistency
is tracked by rdar://problem/20347922.
rdar://problem/22278364
Swift SVN r31325
What does that mean? We'll indeed parse the provided prefix header.
If you aren't using a bridging header, that's all you get -- nothing
extra is made visible. If you /are/ using a bridging header, the prefix
header is prepended to it...but none of the modular content it imports
is made visible. I cloned rdar://problem/22083824 to fix that.
The important thing is that we /won't/ try to import overlays before
we've even finished setting up all the module loaders, and therefore
won't crash.
rdar://problem/20893290
Swift SVN r30831
This is the counterpart of the previous commit---if a class or protocol
is renamed with @objc, we should not be looking for it in Swift under
its Objective-C name.
Finishes rdar://problem/17469485
Swift SVN r29744
The rule changes are as follows:
* All functions (introduced with the 'func' keyword) have argument
labels for arguments beyond the first, by default. Methods are no
longer special in this regard.
* The presence of a default argument no longer implies an argument
label.
The actual changes to the parser and printer are fairly simple; the
rest of the noise is updating the standard library, overlays, tests,
etc.
With the standard library, this change is intended to be API neutral:
I've added/removed #'s and _'s as appropriate to keep the user
interface the same. If we want to separately consider using argument
labels for more free functions now that the defaults in the language
have shifted, we can tackle that separately.
Fixes rdar://problem/17218256.
Swift SVN r27704
Previously, we attempted to infer @objc-ness based on conformance, but
doing so is fraught with ordering dependencies, and just doesn't work
in the general case. Among other crimes, this allowed us to
retroactively mark a non-@objc method from an imported module as
@objc... even though nobody would ever then emit the @objc entry
points for it.
Fixes the rest of rdar://problem/18383574.
Swift SVN r24831
This affects the MacTypes.h header in the Darwin module as well as the
CarbonCore and OSServices sub-frameworks of the CoreServices framework.
API hidden in this way can still be accessed through qualified lookup
in case it's really needed, but will not appear in the module interface
or in code completion.
This is a hack, and it would be nice to remove it if/when all of this API
is officially marked as deprecated. I did check with Nick for MacTypes.h
and Chris Linn from CoreServices that this was a reasonable action to take.
rdar://problem/16806148
Swift SVN r24424
If enums are used as parameters or returns of @objc methods, we may need to forward declare those enums when printing the class @interface.
Swift SVN r23445
To limit user confusion when using conditional expressions of type Bool?, we've decided to remove the BooleanType (aka "LogicValue") conformance from optional types. (If users would like to use an expression of type Bool? as a conditional, they'll need to check against nil.)
Note: This change effectively regresses the "case is" pattern over types, since it currently demands a BooleanType conformance. I've filed rdar://problem/17791533 to track reinstating it if necessary.
Swift SVN r20637
...or at least the same machinery as #line. We add a (referential) mirror
of the Clang buffer to Swift's source manager, then remap that particular
line to whatever Clang currently thinks is the presumed location for that
line. (This means we respect Clang line directives too.)
This also modifies Swift's source manager to be more forgiving about adding
the same virtual file range twice; it will tell you when you try to do it.
<rdar://problem/16596800>
Swift SVN r20572
Now that bridging headers from ASTs are always present and bridging headers
from the command line are checked in advance, we no longer need to worry
about the Clang instance failing to find the bridging header. That's good,
because this wasn't implemented correctly anyway: if a bridging header
imported a module, we could get an error.
Swift SVN r20129
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
In most cases this means adding @public to things that get serialized;
in a few cases it means using a modern public stdlib API instead of
a legacy thing I was trying to keep @internal.
Swift SVN r19350
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
Previously, it had a *nearly* pre-order traversal, but included private
imports before the top-level module being searched. This was leading to
strange errors that relied on search order, like
<rdar://problem/17127940> Qualifying Swift types by their module name doesn't work
Swift SVN r18806
Doing so causes the linker to list the framework itself as one of its
dependencies, which confuses tools that depend on the linker's dependency
output.
<rdar://problem/17006845>
Swift SVN r18578
We're not mapping source locations over correctly yet, so the file name
where an error occurs gets shoved into the diagnostic text, but that's
fine for now.
This also silences the "module 'Blah' not found" error coming from the
importer whenever Swift itself can be responsible for importing the module.
Still to do: if we can't build a Clang module, we shouldn't report that
error and then say it can't be found.
<rdar://problem/14509389>
Swift SVN r18230
Otherwise, it can't find the appropriate ~= to use for synthesized NS_ENUM
RawRepresentable conformances, leading to bizarre errors about the
underlying type (usually Int) not being able to convert to NSObject.
<rdar://problem/16923405>
Swift SVN r18131
This is roughly what happens when debugging a unit test target that imports
an app target, where both the app and the unit test have bridging headers.
Final test for <rdar://problem/16702101>
Swift SVN r17657
This doesn't handle cross-references to decls /loaded/ from the header
just yet, so all that's testable right now is whether the header's imports
are visible from the secondary target (after being imported in response
to loading the serialized module).
More of <rdar://problem/16702101>
Swift SVN r17638
