Implement super.constructor for ObjC superclasses by dispatching the superclass init message with objc_msgSendSuper2. Fixes <rdar://problem/13107128>.
Swift SVN r4288
Replace the more specific Super*RefExpr nodes with a single SuperRefExpr that resolves members of 'this' relative to its superclass. Add an OtherConstructorDeclRefExpr for referring to a constructor as called from another constructor, and use it to represent resolved 'super.constructor' expressions. (It should also be able to represent delegating constructors for free, if we decide we want to add syntax for that.)
Swift SVN r4286
Emit getter and setter ObjC methods and selectors for Swift properties declared in ObjC classes or extensions. If the type of the property is an ObjC class, also emit special-cased ObjC formal property metadata for the property as if it were declared @property (nonatomic, {readonly,strong}) in ObjC.
Swift SVN r4207
We need type metadata symbols for Clang structs so that they have witness tables and can conform to protocols (or be part of structs that conform to protocols). Consider Clang struct metadata to be 'isClangThunk' like other Clang-emitted definitions so that it all gets linkonce_odr'ed to avoid linker issues when multiple TUs import the same modules. Fixes <rdar://problem/13187143>.
Swift SVN r4170
We were just shuttling value types from the objc entry point to the native one at +0 without bringing them up to +1 like the Swift native entry point expects, so things like Slices or closures that got passed through an ObjC interface were getting overfreed.
Swift SVN r4160
The REPL was accreting global_ctors and rerunning all global initializers ever registered before every entry. Change it so that it only runs global initializers once and so that the ObjC initialization stuff that needs to happen on a per-entry basis just gets dropped directly into the main() for each entry.
Swift SVN r4154
When running in immediate mode, generate a global initializer when an extension is defined for an ObjC class that uses the class_replaceMethod runtime function to dynamically add the extension methods to the ObjC class.
Swift SVN r4153
Emit ObjC stubs and categories for methods defined in extensions of ObjC-compatible classes. This makes extensions of ObjC classes available to ObjC in statically compiled code. For immediate-mode code we'll still need to dynamically register extension methods using the ObjC runtime.
Swift SVN r4149
Oops, missed a spot where it was referring to 'DeclAttributes::ObjC' directly instead of going through the accessor. This should make removing [objc] from the examples work.
Swift SVN r4100
Add 'isObjC' as a property of ValueDecl, and set it during type checking if a class is either explicitly annotated with an [objc] attribute or inherits from an isObjC class, or if a func is a method of an isObjC class. Tweak the ClangImporter and other places that summon magic ValueDecl nodes to set up the decls they synthesize as isObjC. Replace logic in typechecking and IRGen that branched on the 'isObjC' attribute to now branch on the 'isObjC' property of ValueDecls.
Swift SVN r4078
As Doug points out, we won't regress here. All Objective-C runtimes we care
about are correctly ignoring this bit.
<rdar://problem/13065246>
Swift SVN r4052
Use UnresolvedSpecializeExprs to set up equality constraints on the opened generic type variables of their subexpressions, and when the system is solved, resolve the expression away to its specialized base expression. Fix the solution logic for DeclRefExprs so that they obtain the type the constraint checker solved for them and not the original unbound type of the decl. This means that constructions and static member accesses of generic types now parse! This also incidentally fixes <rdar://problem/13212959>, so 'A(0)' for generic 'A<T>' now works when T can be inferred from constructor arguments.
One thing that doesn't work yet is generics as type members, as in 'A.B<C>' or 'A<B>.C<D>'. The UnresolvedDotExpr for these generates an unbound type variable, and I'm not sure how to express opening a type variable as a generic type $TO<A, B, C>.metatype constraint system in which the thing being specialized is a variable. This patch also doesn't allow explicit specialization of functions; although we could do so in theory, the constraint system that currently gets generated for functions loses the type parameters, so it would require some redesign in the constraint checker.
Swift SVN r4047
For Objective-C super calls, build an objc_super struct value containing the receiver and class/metaclass object and pass it to objc_msgSendSuper2. For Swift super calls, emit a direct call to the super implementation.
Swift SVN r4023
Fix up the thunk generator so it knows how to turn byval C arguments back into Swift explosions, so that methods that take NSRects as arguments or give NSRect as their return value can be exported as objc methods.
Swift SVN r4010
Push LLVM attribute generation from expandAbstractCC into getFunctionSignature and CallEmission so that they can generate sret and/or byval attributes per-argument according to the calling convention. Copy our bogus rule for emitting sret returns (more than three elements in the explosion) and reuse it to pass large struct values as byvals rather than as explosions. This should be good enough to get both 'NSRect' and
'NSRange', 'NSSize' etc. to pass correctly to ObjC methods. Next step is to set the AbstractCC correctly for imported func decls so that standalone C functions follow the same bogus rule.
Swift SVN r3993
While we don't have a model for overriding methods in Swift extensions yet,
overriding category methods is exactly like overriding any other Objective-C
method, and we shouldn't disallow it.
Swift SVN r3985
Use the same rule for Clang functions and Clang global variables: don't do
anything. Eventually we'll use Clang's mangler to get a proper C/C++
mangling as necessary.
Swift SVN r3961
Per Greg's feedback, this variable obviates the need for a static
constructor when the output is compiled. In interpreted mode, we still
initialize the classes by calling +load ourselves.
This is a fix-up for r3949, but we probably still need a better long-term
solution. See <rdar://problem/13154445>.
Swift SVN r3956
Analyze an expression of the form [<tuple contents>] into a call to T.convertFromArrayLiteral(<tuple contents>) for some T conforming to an ArrayLiteralConvertible protocol. Because of some limitations in the constraint checker and protocol conformance checkers, it currently does an ad-hoc conformance check using member constraints. It also currently fails to typecheck for generic container types, and does not provide a default fallback to 'T[]' if unable to deduce a better type from context.
Swift SVN r3953
When an Objective-C class is first used, the runtime will "realize" it,
i.e. create the rw-data and set a couple flags. With pure Swift classes,
though, it's possible to create an instance and then send a message to it
without ever sending a message to the class, in which case the runtime will
try to realize the /instance/ and mess everything up.
This patch "fixes" that by sending the +load message to all Swift classes,
to make sure they get realized before being used. This is a very
unfortunate cost in startup time but will be necessary for id-compatibility.
I will admit that I'm not sure why this is necessary for compiled classes.
I would have expected the object file to contain the necessary information
for the runtime to realize the classes in it by default. But perhaps
classes aren't realized until their first class message even in statically-
compiled code.
<rdar://problem/13154445>
Swift SVN r3951
Previously, we were relying on objc_retain to retain the closure, but
closure contexts aren't actually id-compatible. Now we use a C++ RAII
object for Swift to manage the closure context retain count.
In the process, Joe and I discovered that the closure context was being
passed to the conversion shim at +0; that has now been fixed to be +1.
Swift SVN r3948
Import C enumeration types as either structs wrapping the underlying
integral type (when the C enumeration type has a name) or as the
underlying integral type (when the C enumeration type has no
name). The structs have a constructor from the underlying integral
type, so one can write, e.g., NSStringCompareOptions(0) to get a
zero-valued enumeration.
Enumerators are imported as a global read-only properties.
Once oneofs start to work, we'll have a way to map some enumeration
types to oneofs, either via a Clang attribute or by sniffing out
NS_ENUM (most likely both).
Once we have static data members of structs working, we'll replace the
global constants with prefix-stripped static variables within the
struct, so we can use ".foo" notation with them.
Once we have constant declarations, we'll map to those instead of
properties.
We can add |, &, and ~ operations are part of
<rdar://problem/13028799> and have not yet been implemented.
Fixes <rdar://problem/13028891>.
Swift SVN r3945
Alter CalleeSource and Callee to keep their own internal vector of substitutions and concatentate multiple SpecializationExpr substitutions. Update EmitPolymorphicArguments::emit to emit arguments out of the substitution list based on the generic parameters of the current function type instead of assuming that the substitution list and generic parameter list match up.
Swift SVN r3937
The mangler was incorrectly walking the full generic param list chain and panicking when mangling nested generic methods because it saw the same archetypes redefined. Since the outer archetypes had to have been mangled as part of the outer context, the deep walk shouldn't ever be necessary.
Fixing this allows you to successfully define a generic method of a generic type; however, you can't call one yet because CallEmission, CalleeSource, and Callee need to learn how to aggregate multiple substitution lists.
Swift SVN r3935
In the StmtChecker, consider a ConstructorDecl or DestructorDecl context to be a function context that returns (). In IRGen for constructors and destructors, set up proper return blocks so that 'return' does the right thing, and in constructors, pretend that the body has no return value even though the underlying constructor mechanism totally returns a value. Fixes <rdar://problem/12950817>.
Swift SVN r3915
In 10.9, the method cache now takes up two words, and the vtable is gone.
Code compiled statically will work fine, but runtime classes need to fill
the rest of the method cache with zero, instead of an address.
I tested this on 10.8 as well and it seems to do no harm.
Swift SVN r3910
Witness table fulfillments for protocol types were being ignored because we didn't record them with the proper key--we were just dropping the protocol on the floor and recording null. Fixing this fixes <rdar://problem/12965934> and obviates r3904.
Swift SVN r3907
We can't naively assume that the allocating constructor's metatype is the very last argument. If there are protocol constraints on the class's generic parameters, those witness tables will get passed in afterward. Add some hacky logic to emitClassAllocatingConstructor to gather witness tables and forward them to the initializing constructor. The added test cases are broken because of <rdar://problem/12965934>.
Swift SVN r3906
Add a mangling for 'block converter' functions and for [objc_block] function types. [objc_block] types also need their own HeapTypeInfo representation that uses ObjC retain/release. When we see a BridgeToBlockExpr, feed the function pointer and context from the Swift closure to the external conversion function and hope we get a block back.
Swift SVN r3899
Provide a BridgeToBlockExpr AST node as a temporary representation of func-to-block conversions. In Sema, when we see an [objc_block] type, insert a BridgeToBlock node and coerce the subexpression to the non-block func type.
Swift SVN r3897
