unexpected forematter from the superclass.
This requires a pretty substantial shift in the
generic-metadata allocation/initialization dance
because (1) we can't allocate class metadata without
knowing what the superclass is and (2) the offset
from the metadata cache entry to the address point is
no longer determined solely by the metadata pattern.
While I'm making invasive changes to metadata, fix
two race conditions in metadata creation. The first
is that we need to ensure that only one thread succeeds
at lazily creating a generic-metadata cache. The second
is that we need to ensure that only one thread actually
attempts to create a particular metadata; any others
should block until the metadata is successfully built.
This commit finishes rdar://17776354. LLDB will
need to adjust to the runtime-private metadata layout
changes.
Swift SVN r20537
functions, and make those functions memoize the result.
This memoization can be both threadsafe and extremely
fast because of the memory ordering rules of the platforms
we're targeting: x86 is very permissive, and ARM has a
very convenient address-dependence rule which happens to
exactly match the semantics we need.
Swift SVN r20381
Create a global alias into the metadata of @objc-visible classes at their address point, which should make these classes visible for linking from ObjC, fixing <rdar://problem/14449644>.
Swift SVN r15921
LLVM doesn't have interior symbols as a first-class concept, so generate module inline asm that defines the OBJC_CLASS symbol relative to the Swift metadata symbol. To prevent our system linkers from considering this symbol as the start of a new object and breaking apart class metadata objects, put the class metadata object into a no_dead_strip section.
This isn't quite enough to get the OBJC_CLASS symbol to be available--the symbol appears to show up in the .o as an undefined symbol and stripped out of the .dylib. John is investigating with the backend and linker teams as to why this is the case.
Swift SVN r14927
Emit vtable entries for abstract initializers. When we're constructing
an object using an abstract initializer based on a metatype value that
is not statically derivable, use the vtable entry to call the
subclass's allocating constructor.
Most of the IRGen work here is hacking around the lossy SILDeclRef ->
(Code|Function)Ref -> SILDeclRef conversion. I'd feel bad about this
if John hadn't already agreed to clean this up at some point.
Swift SVN r14238
Use the 'thin' bit set by SIL to decide whether a metatype lowers to an empty type or not. In GenPoly we still need to accommodate unlowered metatypes to keep protocol witnesses limping along; hopefully that code can be killed soon. With this change we now lower @cc(witness_method) consistently for static methods.
Swift SVN r11535
When we need a reference to protocol or protocol composition type metadata, ask for it through the runtime, instead of referencing statically-emitted protocol metadata.
Swift SVN r9871
When allocating and deallocating dependent generic class instances, load the instance size and alignment from the metadata instead of trying to use a static size from the compile-time class layout.
Swift SVN r9250
"SILConstant" doesn't really describe its role in SIL anymore, which is to provide a reference to a Swift declaration in a SIL instruction, such as a method or nominal type field.
Swift SVN r6559
Provide TypeInfo for class-bounded existentials, which represents them as an explosion comprising one witness table per subscribed protocol and then the class instance pointer as an ObjC-refcounted pointer. Provide lowerings for the SIL instructions that manipulate class-bounded existentials (except for existential-to-existential erasures, which aren't critical to getting basic operations working and will need some abstraction remapping to deal with class-bounded-to-opaque upcasts aside from the representation change).
Swift SVN r5579
Sever the last load-bearing link between SILFunction and SILConstant by naming SILFunctions with their mangled symbol names. Move the core of the mangler up to SIL, and teach SILGen how to use it to mangle a SILConstant.
Swift SVN r4964
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
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
The test changes are that we're setting a class body on
some types that we weren't before. For some of these,
this is okay; for others, it's more questionable, but
ultimately not *harmful*.
Swift SVN r3746
Notably, there is still no support for +1 return values,
so we'll leak when doing alloc/init and so on; but this gets
the fundamentals in place. A lot of the extra stuff in here
is dealing with mapping between metatypes and class objects.
Swift SVN r3425
The interesting thing here is that we need runtime support in
order to generate references to metatypes for classes, mostly
because normal ObjC classes don't have all the information we want
in a metatype (which for now just means the VWT pointer).
We'll need to be able to reverse this mapping when finding a
class pointer to hand off to, say, an Objective-C class method,
of course.
Swift SVN r3424
The principal difficulty here is that we need accessing the
value witness table for a type to be an efficient operation,
but there (obviously) isn't a VWT field for ObjC classes.
Placing this field after the metatype would tend to bloat
metatypes by quite a bit. Placing it before is best, but
it introduces an unfortunate difference between the address
point of a metatype and the address of the global symbol.
That, however, can be fixed with appropriate linker support.
Still, for now this is rather unfortunately over-subtle.
Swift SVN r3307
Introduce a '.metatype' form in the syntax and do some basic
type-checking that I probably haven't done right. Change
IR-generation for that and GetMetatypeExpr to use code that
actually honors the dynamic type of an expression.
Swift SVN r3053
dispatch. Currently there is no possibility of override.
This was really not as difficult as I managed to make it
the first time through.
Swift SVN r2960
of a class is part of the class members section and is not
global to the entire class metadata. This is crucial for
correct operation of functions expecting a base-class
metadata object.
That gives us the correct foundation to implement an
optimization under which generic arguments that can be
inferred from the 'this' pointer need not actually be
separately passed. This has the important result of
making all class member functions with the same signature
up to abstraction actually have the same physical
signature.
Swift SVN r2936
towards optimizing generic calls to derive things from the
'this' pointer, which is actually crucial for virtual
dispatch (to get all methods to agree about how the
implicit arguments are passed). Fix a number of assorted
bugs in metadata emission. Lots of assorted enhancements.
This was proving surprisingly difficult to actually tease
apart into smaller patches.
Swift SVN r2927
