Mock up a naive Printable protocol, and do some dirty tricks in the runtime to implement a 'printAny' function that uses swift_conformsToProtocol to look up a conformance to Printable if the type has one, or falls back to a dumb opaque printing if it doesn't. Use this to make Array<T> Printable in some way or another for all T.
Swift SVN r13902
Given our constraints for 1.0, we can actually sort-of look up protocol conformances just by dlsym'ing the symbol for their protocol witness table, since we won't be implementing runtime witness table instantiation or private conformances anytime soon. To make this work for generic types, distastefully regress our mangling for protocol conformances by assuming all generic conformances are completely general to the unbound generic type and leave the generic parameters out of the mangling.
Swift SVN r13901
This is easier for out-of-process clients like LLDB or DTrace to understand, and will let us mess with the runtime metadata cache data structure without forcing churn on the debugger team.
Swift SVN r13221
Using a linked list for metadata caches is pretty lame. Pull in llvm::DenseMap and hash_combine_range and use them to index instantiated metadata.
The previous attempt at this failed because tuple type metadata was laid out in a way that smashed the metadata cache key. Cache keys used to be laid out like this:
CacheEntry struct
-----------------
cache key
-----------------
variable-sized payload
And TupleTypeMetadata tried to tail-emplace its element array immediately after the main CacheEntry, forgetting the cache key was there. When we actually try to use that cache key to implement a hash table, bad things happen. Rearrange cache entries into the less error-prone layout:
cache key
-----------------
CacheEntry struct
-----------------
variable-sized payload
This also nicely avoids the need for a dynamic offset from the CacheEntry struct to its payload. A tail-allocated payload is likely to be more hot than the cache key, which is only needed at instantiation and lookup time.
Swift SVN r13205
Using a linked list for metadata caches is pretty lame. Pull in llvm::DenseMap and hash_combine_range and use them to index instantiated metadata.
Swift SVN r12998
This lets IRGen avoid emitting an alloca for common generic metadata instantiations. These entry points can also be marked "readnone", and the general getGenericMetadata entry point can be "readonly", giving LLVM's optimizer a fighting chance on unspecialized generic code.
Swift SVN r12789
Start using null-page values as extra inhabitants when laying out single-payload enums that contain class pointers as their payload type. Don't use inhabitants that set the lowest bit, to avoid trampling potential ObjC tagged pointer representations. This means that 'T?' for class type T now has a null pointer representation. Enums with multiple empty cases, as well as nested enums like 'T??', should now have optimal representations for class type T as well.
Note that we don't yet expose extra inhabitants for aggregates that contain heap object references, such as structs with class fields, Swift function types, or class-bounded existentials (even when the existential has no witness tables).
Swift SVN r10061
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
Same deal as for opaque existentials--pre-instantiate a static witness table for one-witness-table types (the zero-witness-tables case is nicely handled by Builtin.ObjCPointer's value witness), and generate a vwtable using dynamic witness implementations for each different-sized container on demand as necessary.
Swift SVN r9850
The assign-with-copy operation on existentials is complex enough to be emitted as a function call, which is currently generated on-demand by IRGen for every existential layout. We can instead use the implementation out of the runtime. Provide entry points for zero, one, and any number of witness tables.
Swift SVN r9815
Metadata.cpp:1280:26: warning: zero size arrays are an extension [-Wzero-length-array]
const void *_witnesses[NUM_VALUE_WITNESSES];
^~~~~~~~~~~~~~~~~~~
Metadata.cpp:1366:12: note: in instantiation of member class
'<anonymous>::OpaqueExistentialValueWitnesses<0>::Container' requested here
/*size*/ Container::size(),
^
Metadata.cpp:1448:51: note: in instantiation of static data member '<anonymous
namespace>::OpaqueExistentialValueWitnesses<0>::ValueWitnessTable' requested here
return &OpaqueExistentialValueWitnesses<0>::ValueWitnessTable;
^
1 warning generated.
As an aside, putting a template argument in ALL_CAPS is kinda wierd.
Swift SVN r9787
Instantiate static value witness implementations for the common zero- and one-witness-table cases, which correspond to the "Any" type protocol<> and to single-protocol types. For protocol compositions, instantiate a value witness table that uses the layout information from existential metadata to perform the value witness operations.
Swift SVN r9752
Set up a metadata cache for existential type metadata. Instantiate existential metadata by first sorting the protocol list, so that it is order invariant, precomputing the overall witness table count and class constraint of the composition so it can be cached in the existential metadata.
We still need to implement value witnesses for existential containers in the runtime before this is complete. We can at least test the uniquing and flags computations at this point.
Swift SVN r9727
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
We'll want to use the same logic to lay out generic struct fields at runtime. While we're here, fix a bug where we weren't aligning field offsets prior to storing them in the tuple metadata.
Swift SVN r9117
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
We haven't fully updated references to union cases, and enums still are not
their own thing yet, but "oneof" is gone. Long live "union"!
Swift SVN r6783