When we see an unresolved @protocol in a Clang module, we now check the name
against the protocols in the Swift module with the same name like we do for
classes.
More <rdar://problem/16295994>
Swift SVN r15472
This keeps us from accidentally stripping off something semantically
meaningful, like in Foundation's NSDirectoryEnumerationOptions:
NSDirectoryEnumerationSkipsSubdirectoryDescendants
NSDirectoryEnumerationSkipsPackageDescendants
NSDirectoryEnumerationSkipsHiddenFiles
<rdar://problem/15496513>
Swift SVN r15436
In Objective-C, all instance methods on a root class are also available as
class methods (because all class objects in Objective-C are instances of the
root class). However, we were incorrectly introducing class methods that
returned 'Self' (instead of 'Self.Type') for every instance method with a
related result type. Returning 'Self.Type' exposes a new type checker bug
<rdar://problem/16414206>, but in practice we don't have much reason to do
this anyway. For now, just don't try to mirror instancetype-returning methods
as class methods.
Swift SVN r15435
..."resolveExternalDeclImplicitMembers".
Now that the ClangImporter has direct access to the type-checker (through
a LazyResolver), there's no reason to bounce through an obtusely generic
interface on ASTContext. Just call through directly to handle the implicit
members and conformances of external decls.
There's no actual functionality change here, though we can probably do
further cleanup in this area.
Swift SVN r15356
When we see an unresolved @class in a Clang module, we check the class name
against the classes in the Swift module with the same name.
This unfortunately necessitates putting a reference to the active type checker
into the ClangImporter, because the class in the current Swift module hasn't
been type-checked yet. This is now being used everywhere we do a lookup.
<rdar://problem/16295994>
Swift SVN r15355
(and protocols)
I had missed this check before. It probably made very little difference, but
we use "hasClangNode" to mean "defined-in-Objective-C", so it's better to get
this correct.
The test change is fairly minimal: not giving the class a Clang node means we
have to find it by lookup, but the Objective-C part of the "Base" module
wasn't actually considered visible by Clang. In a real situation the "Base"
module would be a proper framework and both halves of the module would have
been imported, as tested by the mixed-language test.
Swift SVN r15248
of 'init' method family with Clang (it looks like 'init123' would count as init
method in Clang, but not in the initial implementation of selector splitting in
Swift).
Swift SVN r15189
The frontend option -split-objc-selectors splits the first part of an
Objective-C selector into both a function name and the first parameter
name at the last preposition. For example, this Objective-C method:
- (NSString *)stringByPaddingToLength:(NSUInteger)newLength withString:(NSString *)padString startingAtIndex:(NSUInteger)padIndex
is imported as
func stringByPadding toLength(newLength: Int) withString(padString: String) startingAtIndex(padIndex: Int) -> String
Swift SVN r15156
In a framework containing both Clang headers and a Swift module, the Swift
module gets picked up first, but then automatically imports (and re-exports)
the Clang module as well.
One interesting case here is that it's possible for the Clang side to add
categories to a class declared in Swift. In order to support this, the
Clang importer can now find extensions for Swift classes marked @objc.
(I couldn't think of a way to test this separately; the previous commit
was supposed to do that, but worked without this change.)
<rdar://problem/16295937>
Swift SVN r15084
There are very few times where we'd want to use @class_protocol outside of
@objc, and it feels weird to tell someone coming from Objective-C that they
need to mark their already-@objc protocol as @class_protocol. Instead, just
change ProtocolDecl::requiresClass to check for @objc.
(The commit checks for /both/ @objc-the-attribute and the IsObjC flag.
This is to give the right answer before type-checking, or at least the
likely-intended answer.)
<rdar://problem/16302887>
Swift SVN r15060
If a subclass defines no subobject initializers and all of its stored
properties have initial values, "inherit" all of the subobject
initializers of its superclass by creating a new initializer with the
same signature that overrides (and chains to) the corresponding
subobject initializer of its parent. Do this instead of blindly
creating a default initializer.
Note that we aren't yet doing this for generic initializers. That will
be a separate step.
Swift SVN r14995
This is the same as the previous commit, but for protocols. To do this I
had to modify the ObjC printer to include a SWIFT_PROTOCOL annotation like
the SWIFT_CLASS annotation already in use. This is probably a good thing
anyway.
Second half of <rdar://problem/16296027>
Swift SVN r14985
This is necessary to handle Swift code using API defined in Objective-C
that itself uses classes defined in Swift. Protocols coming next.
First half of <rdar://problem/16296027>
Swift SVN r14984
...so that the Clang module machinery will check that the generated pcm
is up-to-date.
We probably want this to be considered a system header in the long run,
but this is a quick fix for those working on the standard library.
<rdar://problem/16285900>
Swift SVN r14926
In Sema, give derived '==' definitions the module's DerivedFileUnit as their decl context instead of the more general Module, and give it a backreference to the nominal type for which it was derived.
In SILGen, visit the derived global decls associated with Clang-imported enums, and give them shared linkage. Part of fixing <rdar://problem/16264703>.
Swift SVN r14875
When importing an Objective-C class, import all of the initializers in
all of its superclasses. When we have no information about designated
initializers for a class, the initializers come in as subobject
initializers. When we do have information about designated
initializers, we (1) use it to sort out subobject from complete object
initializers in that class, and (2) assume that all initializers from
superclasses are complete object initializers. Overall, this better
matches Objective-C's semantics.
Swift SVN r14841
The standard library likes to have default definitions for associated types,
which is good. Often the /choice/ of default type, however, is a type that
(indirectly) conforms to the very protocol containing the associated type.
Rather than try to make sure everything is present all at once, just delay
the deserialization of the default definition until it's actually requested.
This does swell the size of AssociatedTypeDecl by two words. I've filed
<rdar://problem/16266669> to remind myself to try to reduce this.
Part of <rdar://problem/16257259>
Swift SVN r14809
In these cases, disable the standard system include paths so we don't
accidentally pick up headers in /.
This is going to be used by the runtime team for low-level interfaces with
C and Objective-C in the standard library.
Swift SVN r14789
Make the name lookup interfaces all take DeclNames instead of identifiers, and update the lookup caches of the various file units to index their members by both compound name and simple name. Serialized modules are keyed by identifiers, so as a transitional hack, do simple name lookup then filter the results by compound name.
Swift SVN r14768
'Protocol' is the class used by Objective-C to refer to the runtime metadata
for a protocol. It's used by APIs such as NSXPCConnection. The class is
defined as "@interface Protocol : NSObject" in the modern Objective-C runtime.
This is a workaround for a Clang bug, PR19061 / <rdar://problem/16244450>.
We ought to be able to see the definition of Protocol whenever the
ObjectiveC module is loaded, but right now we can't. Once that bug is fixed,
this change should be reverted.
<rdar://problem/16229963>
Swift SVN r14761
This will allow us to ship headers that are used by the standard library.
They will be treated as system headers.
<rdar://problem/16227202>
Swift SVN r14757
NSStringEncoding does not use NS_ENUM for various reasons. This importer
change makes NSStringEncoding's type match its intended values' types.
Old workarounds that used extra NSStringEncoding casts will need to be changed.
Example:
- var enc = NSStringEncoding(NSUTF8StringEncoding)
+ var enc = NSUTF8StringEncoding
Swift SVN r14720
This reverts part of r14563, which swapped out the mirroring of
Objective-C initializers into subclasses. We still need to do this
when a subclass does not declare it's designated initializers. At
least the mirroring code is more robust, and marks declarations as
implicit so they won't show up when printed.
Swift SVN r14633
Make Objective-C initializers inherited according to the inheritance
rules we've specified. Prevent the Clang importer from manually
copying all of the initializers from every superclass into each
class.
This eliminates a ton of extra allocating constructors generated when
importing Objective-C init methods. Now we only generate allocating
constructors for the init methods that are actually declared.
Note that initializer inheritance only actually works for
Objective-C-defined classes. More to come.
Swift SVN r14563
