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
ObjC methods always need to be invoked through objc_msgSend, so they shouldn't have vtable slots, and Swift subclasses that override ObjC methods should always insert override slots into their vtables.
Swift SVN r3889
Differing from C will only surprise people. If we want some new do/while
like loop construct that does not evaluate the condition after a
"continue" statement, then we should call the loop construct something
else or invent some kind of new "startover" statement.
Swift SVN r3881
In the SIL for a destructor I emit a call to the base class destructor. Although destructors show up in SIL as their decl type T -> (), internally, they all share an LLVM function type void (%swift.refcounted). If an ApplyInst applies to a destructor, bitcast its argument.
Swift SVN r3875
It looks like CallEmission::emitToExplosion sets up cleanups on its outputs, and I didn't see an immediately apparent way to do so, so this is just a quick hack to scrub those cleanups so they don't interfere with SIL-IRGen.
Swift SVN r3874
Emit separate entry points for the allocating and initializing constructors. 'super.constructor' now works for the small subset of cases for which I've implemented sema support.
Swift SVN r3864
Static methods and constructors receive class metadata from which they can derive their polymorphic parameters, so adding additional metatype arguments to the function is redundant.
Swift SVN r3862
Recognize super.constructor calls in IRGen and generate them as calls to the superclass initializing constructor. Note that super.constructor code still won't execute just yet because classic IRGen doesn't generate initializing constructors.
Swift SVN r3859
ObviouslUilabilityMacros.h is not the way to go when we're building against
10.9 SDKs on 10.8 systems. Since this is a temporary hack anyway, just make
it based on the the host syatem ake configuration time, and disable the
failing tests on 10.9.
Swift SVN r3851
Set up AST nodes for 'super.<identifier>', 'super.constructor', and 'super[<expr>]' expressions, and implement parsing for them without any sema or backend support.
Swift SVN r3847
The libobjc in current builds can't handle it. <rdar://problem/13046897>
We are going to want this bit set, though, so this hack should be
removed once a new libobjc is available. <rdar://problem/13065246>
Swift SVN r3839
Emit the SIL destructor as a destroying destructor, then emit a deallocating destructor shim that calls into it and then returns the heap size. (The actual deallocation still happens in swift_release--I talked to John about that and I'll fix it later.) This gets the broken SIL/IRGen class tests passing again.
Swift SVN r3838
IRGen was generating the exact same signature for the initializing/allocating constructors and destroying/deallocating destructors. Make it do the right thing by typing the initializing constructor as Swift T -> (...) -> T and the destroying destructor as LLVM void(%swift.refcounted*). (This will later change to '%swift.refcounted*(%swift.refcounted*)' pending some irgen/runtime cleanup.)
Swift SVN r3837
Remove the filter that only irgenned SIL functions for FuncDecls so that we emit functions for all SIL decls, and disable the old paths for properties, constructors, and destructors when a SIL module is present. Unfortunately this breaks class constructors because SIL and IRGen don't agree on how initializing constructors should work. I need to sync with John to figure out how to fix that.
Swift SVN r3827
Implement AllocRefInst so that SIL-emitted constructors can be irgenned. Factor the code for allocating a class instance from GenClass's emitClassConstructor function.
Swift SVN r3826
We have no intention of ever supporting actual semicolon statements
(separators, statements no), nor do we ever want to because that would
mean the behavior of the program would potentially change if semicolons
were naively removed.
This patch tracks the trailing semicolon now in the decl/expr/stmt,
which will enable someone to write a good "swift indent" tool in the
future.
Swift SVN r3824
Make the SIL visitor path a bit less hacky by more cleanly separating the AST walk to find types to codegen from the SIL module walk to find functions to codegen. This way, local functions and other such entry points from SIL actually get generated, and the closures test works.
Swift SVN r3820
Implement lowering of SIL ClosureInsts by packing the partial arguments into a heap allocation and emitting a thunk to unpack them and apply the closure function, similar to curried entry points. The test doesn't work quite yet because nested FuncDecls don't get visited anymore. I need to replace my hacked SIL path with a proper walk of the SIL module to generate functions and the AST to generate types.
Swift SVN r3817
These let SILGen retain and release arbitrary Explosions without having to work around cleanups. Also remove 'transfer' because I'm dumb and didn't realize 'reexplode' already does the same thing.
Swift SVN r3816
and non-deallocating destructors and allocating/non-allocating
constructors.
Non-deallocating destructors might not play well with ObjC
classes; we might have to limit them to pure-swift hierarchies.
No functionality change except that I decided to not force
destructors to have internal linkage unconditionally.
Swift SVN r3814
Previously, we were mangling [objc] class types as swift
classes (using the defining component in the mangling) and
imported class types as class types with empty contexts.
This could create an inconsistency between components which
disagree about whether an ObjC class is defined in swift or
not; this will not do. Also, an empty context creates an
invalid mangling.
Swift SVN r3812
This attribute is now a way to mark that a class should be
exported as a normal Objective-C class, not a way to declare
an external Objective-C class.
Swift SVN r3806
The ObjC ABI requires these class fields to be initialized by
resolving symbols from the runtime. So this is a historical
requirement. Note that there is a desire to optimize this
even for ObjC, because in a project with many classes, these
can actually end up representing a significant fraction of
the external non-lazy relocations in the linked image. But
for now we follow the spec, as we must.
The ObjC ABI requires these to be taken from the runtime,
although there is an effort to make them not require external
relocations like this, since in large projects it can actually
add up to a large percentage of the non-lazy external relocs.
3,6d
2i
Swift SVN r3804
