- Merge availability info by merging CommonEntityInfo as part of ObjCContextInfo.
- Don't try to add Absent nullability to property setters (since it cannot be
represented by ObjCMethodInfo).
- Factor out lookupObjCContext and make sure we always look up in both
class and protocol.
This will be tested by API notes drop, which will get committed separately.
Swift SVN r22089
Some of the buffers are owned by the ClangImporter, so after the
ClangImporter's been deallocated, the SourceManager isn't going to be fully
valid any more.
Should fix issues from r21958.
Swift SVN r21989
Removes the initWithBool: hack from the Clang importer. We can now
express NSNumber's conformance to the BooleanLiteralConvertible
protocol in the overlay.
Swift SVN r21976
Conforming to BooleanLiteralConvertible now requires
init(booleanLiteral: Bool)
rather than
static func convertFromBooleanLiteral(value: Bool) -> Self
This posed a problem for NSNumber's conformance to
BooleanLiteralConvertible. A class needs a required initializer to
satisfy an initializer requirement, but one cannot add a required
initializer via an extension. To that end, we hack the Clang importer
to import NSNumber's initWithBool with the name
init(booleanLiteral:)
and add back the expected init(bool:) initializer in the
overlay. These tricks make NSNumber even harder to subclass, but we
don't really care: it's nearly impossible to do well anyway, and is
generally a Bad Idea.
Part of rdar://problem/18154091.
Swift SVN r21961
Once can use ClangModuleLoader::getImportedHeaderModule() to check if the module is the importer-header module.
This reverts commit r21949.
Swift SVN r21955
We don't do this very efficiently, but it does work. And now that it's working,
drop some special cases in module interface printing -- just always print
Clang decls in Clang source order.
Swift SVN r21901
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
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
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
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
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
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
...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
