When we print the ObjectiveC module, we really shouldn't see extensions that
come from Foundation. Admittedly, we don't see them correctly in Foundation
either, but that's a separate issue.
There is one slightly unsafe hack here: we still import NSString as String,
by name alone, even when Foundation isn't present. This is because NSString
shows up in the ObjectiveC module, but we want people to be using String
when interacting with NSObject in real life.
Swift SVN r21857
This can be used by SourceKit's interface printer to display modules with
forward declarations of classes in dependent modules, e.g. ObjectiveC
forward-declaring Foundation's NSString for use in NSObject. We can consider
doing something similar for C tag types (structs and enums).
Part of rdar://problem/18273845
Swift SVN r21828
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
Redefine the RawRepresentable protocol to use an 'init?' method instead of 'fromRaw(Raw)', and a 'raw' get-only property instead of 'toRaw()'. Update the compiler to support deriving conformances for enums and option sets with the new protocol. rdar://problem/18216832
Swift SVN r21762
This is a hack that allows us to support accessibility APIs in Swift.
It addresses radar://17509751.
A class might conform to both NSAccessibility (containing accessibility
properties) and individual accessibility protocols (containing
accessibility methods with the same names as the properties). This should
not compile (but currently happens to compile). To avoid the problem down
the road, we import setters and getters instead of the accessibility
properties from NSAccessibility.
Swift SVN r21757
Specifically, it should not ever have a clang::TypedefDecl as its Clang node,
even if the RecordDecl is anonymous and immediately wrapped in a typedef.
It looks like no one was ever doing this intentionally; it's just left over
from before we looked through typedefs at all. This is important because we
use the clang::RecordDecl for IRGen layout if it's present; before this patch
we would fall back to Swift layout for these structs (clearly wrong).
The one exception here is enums -- NS_OPTIONS and named C enums get imported
as structs as well. If we add any other exceptions, we should be sure they
are dealt with in IRGen as well.
The change in the printed interface output is due to the source location
for the Clang node of an NS_ENUM or NS_OPTIONS decl being inside a macro.
I didn't see a quick fix for this, so I'm going to ignore it for now.
Swift SVN r21748
When determining whether one imported initializer stomps on another,
use the parameter types rather than the full type. This prevents
differences in failability from causing ambiguities.
Swift SVN r21692
We currently mangle private declarations exactly like public declarations,
which means that private entities with the same name and same type will
have the same symbol even if defined in separate files.
This commit introduces a new mangling production, private-decl-name, which
includes a discriminator string to identify the file a decl came from.
Actually producing a unique string has not yet been implemented, nor
serialization, nor lookup using such a discriminator.
Part of rdar://problem/17632175.
Swift SVN r21598
Nor is ConstFSEventStreamRef.
Unfortunately, they both get bridged to COpaquePointer, so they're not
constructible from one another--they're identical.
rdar://problem/18112747
Swift SVN r21546
I'm not quite sure how to tickle this one, but the next commit adds more
data after the cached header, at which point existing tests break. This
could have already caused problems if no padding was needed in the bitstream.
Swift SVN r21543
Introduce an attribute that describes when a given CF type is
toll-free-bridged to an Objective-C class, and which class that
is. Use that information in the type checker to provide the CF <->
Objective-C toll-free-bridged conversions directly, rather than using
the user-defined conversion machinery.
Swift SVN r21376
Depending on visitation order, we would occasionally leave the factory
method available if we had completely imported the initializer
first. Fixes <rdar://problem/17261609>.
Swift SVN r21361
In this mode, use nullability information on the result type of the
initializer or factory method to determine failability of the
initializer. This is behind the flag
-enable-objc-failable-initializers until we have the SILGen support in
place.
Swift SVN r21341
This regresses a bit on the diagnostic when a submodule is missing, as well
as missing out on Clang's automatic typo correction, but it does avoid putting
the Clang CompilerInstance into an error state, which is important for the
REPL. It's also not entirely clear that Clang had the right behavior in this
case either---we'd get a module back, but if the particular submodule we
asked for didn't exist we might get its parent. We can revisit this later.
Prerequisite for <rdar://problem/17994094>.
Swift SVN r21333
i.e. don't look for attributes on an @class somewhere.
Also do this for tag decls, whose attributes propagate forwards until there's
a definition.
<rdar://problem/17986861>
Swift SVN r21223
This makes sure that the Clang CompilerInstance doesn't think that we've seen
an error just because we were checking for the existence of a module, and
therefore will not break the world when the module is absent.
This fixes an issue where loading PlaygroundLogger broke static inline
functions because PlaygroundLogger has no Objective-C module.
<rdar://problem/18007508>
It also lays groundwork for not treating a missing module as a fatal error
in REPL modes. To do that properly, however, we should figure out how to do
this for submodules as well. <rdar://problem/17994094>
Swift SVN r21187
Without this, we try to bring these in as CF types, and then ARC tries to
manage them, and the program crashes.
<rdar://problem/17211521>
Swift SVN r21081
This handles things like NSSwapHostLongLongToBig and MKMapRectMake that
are static inline functions that themselves call other static inline
functions.
<rdar://problem/17227237>
Swift SVN r21080
This requires a bit of special handling because we override the getter's type
in the importer, to make sure it's compatible with the setter, but other than
that we just use the information from the apinotes file.
<rdar://problem/17891179>
Swift SVN r21027
This is a step towards making the framework easier to use in Swift; in the
actual headers, these are typed as "CFTypeRef" or "const CFTypeRef", which
is not considered Hashable (and thus cannot be put in a dictionary).
Unfortunately, CFStringRef is also not hashable, so we're not there yet,
but at least this allows a freer conversion to NSString.
Part of <rdar://problem/17162475>
Swift SVN r20931
Background: if a Clang module /only/ imports submodules from another module,
we would lose all re-exports from that other module, because we're treating
all decls as part of the top-level module. This actually shows up with UIKit
and QuartzCore due to some weirdness in how the QuartzCore module is set up
(see <rdar://problem/17888079>), resulting in 'CALayer' not being visible
with just 'import UIKit'.
Workaround (this patch): treat Clang imports just like Swift imports: if the
submodule is referenced, so is the top-level module. This isn't great, but
it's not really any more awful than the rest of our Clang modules story.
<rdar://problem/17607060>
Swift SVN r20920
This is already a fatal error, so it doesn't matter how many diagnostics we
dump after that. It's better not to lie to the rest of the compiler about
whether the load succeeds.
No immediate Radar, but this fixes a crash in the test case I'm about to
commit, and possibly some other mystery "dependency missing" crashes in
XREF resolution.
Swift SVN r20919
This completes <rdar://problem/17024498>, except that we don't yet do
anything with 'deprecated' or 'obsoleted'. The former is covered by
<rdar://problem/17406050>, and I filed <rdar://problem/17873422> for the
latter.
Swift SVN r20845
