@partial_interface is like @class, but it allows the user to write categories
or (eventually) subclasses in their Objective-C headers even though the
class will be implemented in Swift. The resolution rules are thus exactly the
same as for class.
I've included a template hack to allow you to keep building without switching
to the new internal Clang repo; in this case you will see one test failure.
<rdar://problem/16426884>
Swift SVN r15523
You can't actually call these initializers with an existential yet, but nor could you safely call the init methods anyway. At least you'll be able to conform to NSCoding with an initializer rather than an "init method". Fixes <rdar://problem/15595471>.
Swift SVN r15521
This significantly reduces the amount of overhead incurred when naively importing large external modules without referencing many of its members, which should directly improve response times in the playground. For example, the repro code attached to rdar://problem/16387393 imports Foundation but references none of its members, and with these changes its total compilation time is almost 2.5x faster.
Swift SVN r15479
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
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
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
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
'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 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
If an enum has no cases with payloads, make it implicitly Equatable and Hashable, and derive default implementations of '==' and 'hashValue'. Insert the derived '==' into module context wrapped in a new DerivedFileUnit kind, and arrange for it to be codegenned with the deriving EnumDecl by adding a 'DerivedOperatorDecls' array to NominalTypeDecls that gets visited at SILGen time.
Swift SVN r14471
There are two parts to this:
- Import protocol properties as properties, instead of as a pair of methods.
- Fix IRGen to handle property accesses in @objc protocols.
<rdar://problem/12993073>
Swift SVN r14438
This is hidden behind the frontend flag -enable-objc-optional. Use -Xfrontend
when invoking the Swift driver.
Part of <rdar://problem/15189135>
Swift SVN r14332
Right now we have a hack to mirror ObjC protocol methods into an imported
ObjC class, because Swift's lookup only looks into superclasses, not into
protocols (by default, anyway). This already isn't great because it's wrong
for @optional, but it was particularly bad if /two/ superclasses conformed
to the same protocol (directly or indirectly). Because the mirrored methods
weren't marked as overrides, the type checker would consider them both as
possibilities, leading to strange errors like this:
<REPL Input>:1:1: error: ambiguous use of 'description'
w.description()
^
AppKit.NSWindow:268:8: note: found this candidate
func description() -> String
^
ObjectiveC.NSObject:72:8: note: found this candidate
func description() -> String
^
Now, we check to see if a superclass conforms to a protocol already before
mirroring its methods into the current class or category.
<rdar://problem/16102321> and possibly also <rdar://problem/16038085>
Swift SVN r14189
We will still import these as just 'Int', 'UInt', etc., but we still want to
allow users to write some of these types themselves. We now have an enum field
in MappedTypes.def to control this.
Fix-up for r14069 and <rdar://problem/16067854>
Swift SVN r14105
...rather than Int.
This handles the case where there are existing 32-bit enum constants with
the bit set, which isn't that uncommon for NS_OPTIONS declarations.
Part of <rdar://problem/15368372>, but should also fix the main issue in
<rdar://problem/15236662>.
Swift SVN r14090
separately from the get/set value. There is no exposed way in the
source language to use this, and this causes shorter term annoyance.
I chose to flatten the value and indices so the value comes first.
In principle, this allows us to completely eliminate our ObjC importer
thunks. I haven't removed them though, because they might be useful
for something else.
Swift SVN r14049
This is more in line with all other modules currently on our system.
If/when we get our final name for the language, we're at least now set
up to rename the library without /too/ much trouble. (This is mostly just
a lot of searching for "import swift", "swift.", "'swift'", and '"swift"'.
The compiler itself is pretty much just using STDLIB_NAME consistently now,
per r13758.)
<rdar://problem/15972383>
Swift SVN r14001
GenericSignatures with no params or requirements are a bug, so verify that they don't happen by making GenericSignature::get return null and GenericFunctionType assert that it has a nonnull signature. Hack Sema not to try to produce nongeneric GenericFunctionTypes when a function in a local type in a generic function context is type-checked; there's a deeper modeling issue that needs to be fixed here, but that's beyond the scope of 1.0. Now that GenericSignature always has at least one subtype, its factories no longer need an independent ASTContext argument.
Swift SVN r13837
Change GenericFunctionType to reference a GenericSignature instead of containing its generic parameters and requirements in-line, and clean up some interface type APIs that awkwardly returned ArrayRef pairs to instead return GenericSignatures instead.
Swift SVN r13807
