...rather than distinct classes. This is a bit more complicated than just
making a second typealias because we still want to strip off the "Ref".
<rdar://problem/17686069>
Swift SVN r20652
If importing a Clang module fails, we should report that at the location of
the import statement. This doesn't do that fully because it isn't transitive
(if Swift module Foo imports Swift module Bar, which fails to import Clang
module Baz, we don't get an error in user source), but it's a step forward
for the simple cases.
Swift SVN r20575
This replaces my egregious -initWithCoder:-specific hack with a more
reasonable general solution.
Replace my initWithCoder: hack with a proper
Swift SVN r20562
This allows us to express required initializers in the API notes. Use
it to smooth over NSString differences in the various SDKs even more.
Swift SVN r20511
We choose not to model "OptionalTypeAdjustment(1, OTK_Optional)" in yaml, so update the known methods to use what we can model.
Introduce the absence of nullability info and use it to set NullabilityAudited and NumAdjustedNullable. (Maybe, after the .def file is gone and we have more testing, we could change the KnownObjCMethod API to better reflect the yaml format..)
Swift SVN r20367
Specifically, handle them by also importing the top-level module. This is
unfortunate, but at least lets people /access/ things in explicit submodules,
even if it doesn't let them limit their import to a specific submodule.
(swift) import OpenGL.GL3
(swift) glGetString
// r0 : (GLenum) -> ConstUnsafePointer<GLubyte> = (Function)
(swift) OpenGL.glGetString
// r1 : (GLenum) -> ConstUnsafePointer<GLubyte> = (Function)
One unfortunate side effect of having a single Clang ASTContext is that if
one Swift module imports a Clang submodule, every Swift module can now see
it. That means /mixing/ incompatible submodules, such as OpenGL.GL and
OpenGL.GL3, still won't work. Filed <rdar://problem/17756745> for that.
<rdar://problem/13140302>
Swift SVN r20288
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
it indirectly through another pointer from Decl, just embed DeclAttributes
directly into Decl and get rid of the "getMutableAttrs" nonsense.
Swift SVN r20216
Make the "merging class-wide information into method information"
operation part of ObjCMethodInfo. It doesn't belong in the Clang
importer.
Swift SVN r20171
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
We do this so that the swiftmodule file contains all info necessary to
reconstruct the AST for debugging purposes. If the swiftmodule file is copied
into a dSYM bundle, it can (in theory) be used to debug a built app months
later. The header is processed with -frewrite-includes so that it includes
any non-modular content; the user will not have to recreate their project
structure and header maps to reload the AST.
There is some extra complexity here: a target with a bridging header
(such as a unit test target) may depend on another target with a bridging
header (such as an app target). This is a rare case, but one we'd like to
still keep working. However, if both bridging headers import some common.h,
we have a problem, because -frewrite-includes will lose the once-ness
of #import. Therefore, we /also/ store the path, size, and mtime of a
bridging header in the swiftmodule, and prefer to use a regular parse from
the original file if it can be located and hasn't been changed.
<rdar://problem/17688408>
Swift SVN r20128
We're not using this for anything, yet, so there aren't any checked-in
tests. Also note that I'm using ".apinotesc" for the binary form of
API notes.
Swift SVN r20096
This is a hack to work around two issues:
- <iso646.h>, which defines macros for "and", "or", and "not" (among other
things) is an implicit submodule of Darwin.
- Macros even in explicit submodules are leaking out when the parent module
is imported <rdar://problem/14870036>.
There's no actual reason to require <iso646.h> in SDK header files -- it
should be a user-level choice whether or not to use those names. And
selectors with "and", "or", and "not" in them should not be mangled by this.
So, as a hack, we define the header guards that <iso646.h> uses ahead of
time, so that the file will be ignored. We do this for /both/ variants of
<iso646.h> on our system (Clang's and /usr/include's) just to be safe.
<rdar://problem/17110619>
Swift SVN r19822
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
Add the ability to store optionality of the ObjC method parameters and return
type in a sidecar. This hardcoded info is then used to import Objective C
object pointer types as either optional or none, instead of implicitly
unwrapped optionals.
The feature is enabled with -import-with-tighter-objc-types=true.
Swift SVN r19048
.../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
Until we can build against LLVM and Clang master completely, we should hold
off on any changes that take us out of sync with the wwdc-master tags.
This reverts r18661.
Swift SVN r18662
This is -Werror=non-modular-include-in-framework-module for Clang, and
prevents the same content from being treated as part of two different
modules. It's mostly just a sanity check to keep from having problems later.
<rdar://problem/16966705>
Swift SVN r18525
Use this for -class and +class, to make them less ad hoc. More to follow.
As part of this, actually mark imported unavailable declarations in a
protocol as "optional", because nobody should have to implement an
unavailable declaration.
Swift SVN r18262
