No reason to try to shove the kind-dependent bits after the tail-emplaced generic parameter description. Let's plan to put the field names in here too so we can give a reasonable lowest common denominator display for aggregates even without debug info.
Swift SVN r9490
In the short term LLDB needs to be able to find and parse generic parameter vectors and field offset vectors from metadata records without necessarily having the debug info necessary to do so. Start off the descriptor by including these offsets and lengths.
Swift SVN r9458
Does what it says on the tin: lays out the fields, storing their offsets into the metadata, and initializes the size, flags, and stride of the value witness table.
Swift SVN r9120
Add functions to dynamically query the extra inhabitants of a single-payload union's payload metadata, then identify or store bit patterns used to represent empty cases, whether they happen to use extra inhabitants or added tag bits.
Swift SVN r8320
Instead of hardcoding a walk of a list of fill ops, have generic metadata templates carry a pointer to a fill function for swift_getGenericMetadata to invoke to perform the fill operations. For types with dynamic layout, we will need to be able to perform more complex fill operations than a simple transfer of arguments into generic metadata slots.
Swift SVN r7893
Instead of letting swift_NSStringToString leak malloced memory, use swift_allocPOD to allocate storage for the converted String, and stash the heap object into the created string.
Swift SVN r7872
swift_allocPOD allocates a heap object capable of holding POD data of some given size and alignment. This will allow 'alloc_box' and 'alloc_array' to lower specially without instantiating do-nothing heap metadata for POD types, as described in <rdar://problem/13129334>. Update the dynamic swift_allocBox entry point to use swift_allocPOD for POD types. This can also be used by other runtime functions that need to allocate reference-counted scratch memory, such as swift_NSStringToString, as noted in <rdar://problem/14646715>.
Swift SVN r7860
Standardize on the more-common "superclass" and "subclass" terminology
throughout the compiler, rather than the odd mix of base/derived and
super/sub.
Also, have ClassDecl only store the Type of the superclass. Location
information will be part of the inheritance clause for parsed classes.
Swift SVN r6687
Add swift_dynamicCastIndirect and swift_dynamicCastIndirectUnconditional runtime functions, which take an opaque value pointer and source and target type metadata and do a checked cast on the opaque value, calling down to dynamicCast for class casts or doing static equivalence checks for non-class casts.
Swift SVN r5681
This is a workaround for <rdar://problem/13986638>, since the compiler doesn't yet generate metadata for oneof types (and the final layout of oneof metadata is TBD).
Swift SVN r5360
storage in a flags word in the value witness table. Pack the
alignment into only 16 bits of this word. Optimize tuple value
witnesses based on whether they're POD and inline.
Swift SVN r5138
that handle the 2/3 element cases specially. These are not actually
optimized at the moment (they just call into swift_getTupleTypeMetadata)
but this could be done at some point.
This is a win for a couple reasons: this reduces the amount of code generated
inline and it allows swift_getTupleTypeMetadata2/3 to be marked readnone,
enabling CSE. As a driveby, optimize metadata refs of zero element tuples
to directly use _TMdT_, eliminating a branch from swift_getTupleTypeMetadata.
Swift SVN r5070
Emit the deallocObject runtime call inside the deallocating destructor for a heap object, instead of inside swift_release. This will allow for heap objects with known size to directly call fast deallocator entry points and potentially custom deallocators in the future.
Swift SVN r5027
To be able to get the dynamic type of a generic value, the 'typeof' operation needs to be part of the value witness for the type. Add 'typeof' to the value witness table layout, and in the runtime, provide standard typeof witnesses for static, Swift class, and ObjC class values.
Swift SVN r5013
Per John's comments, make a GenericBox struct to represent the layout of a generic box allocation, move all the layout calculations into methods on GenericBox, and alter swift_deallocBox to take the type as an argument so that it's future-proofed for when we start special-casing certain types in allocBox.
Swift SVN r4613
Add a runtime function that, given a generic type metadata pointer, allocates a heap object capable of containing a value of that type. This is a first-pass implementation that always does the worst case thing of stuffing the type metadata into the box with the value and using its value witness table to size, align, and destroy the box. Use swift_allocBox to implement ArchetypeTypeInfo::allocate correctly for heap object allocations. This means SIL's alloc_box $T now works for archetypes, and a simple generics test now (almost) compiles through SIL!
Swift SVN r4599
The "Kind" field for class metadata is an isa pointer and not a member of MetadataKind, and so the switch in swift_dynamicCast was falling out and casting to an uninitialized pointer. Guard Metadata behind some accessor methods that do the right thing and update dynamicCast.
Swift SVN r4525
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
Cocoa allows objects to override -isKindOfClass: to lie about their class.
As bad as it is, Swift should respect that. <rdar://problem/13013432>
Note that this clashes with the SWIFT_DISABLE_SWIFT_BIT_ON_CLASS_DATA hack;
on 10.9 -isKindOfClass: will always be used. In the long run, we don't
really want to ask if the target /type/ is an Objective-C type, but rather
if the target /object/ is an Objective-C object.
Swift SVN r3911
Introduce a new swift_dynamicCast pair that take in a general metatype
pointer, rather than the more specific class-metatype pointer used for
class downcasts, and grab the class out of that general metatype
pointer, which may actually be an Objective-C wrapper. This is
slightly slower, but it works for the super-to-archetype cases like
T(an_NSObject), where T can have either kind of metadata.
NSTypedArray<T> is actually run-time type checked now, yay!
Swift SVN r3564
This variant of swift_dynamicCast requires us to have data that's
guaranteed to be class metadata, but it's not always natural to
generate class metadata. No functionality change yet.
Swift SVN r3562
We add a new runtime entry point, swift_dynamicCastUnconditional(),
that aborts when the cast fails. We'll probably want to throw an
exception in the future, but this is fine for now.
Swift SVN r3554
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
