This mostly falls out from the metatype cast infrastructure, but we need to generalize some Sema and SILGen code to accept AnyMetatypeType. Concrete-to-existential metatypes will need more runtime checking that isn't implemented, so raise a 'not implemented' error on those for now.
Swift SVN r17798
Centralize the logic for figuring out what name to use for a class or
protocol in the Objective-C runtime. When the flag is enabled (it's
still disabled by default), use mangled names for all Swift-defined
classes, including those that are @objc. Note that the naming is
determined in the AST, because we're also going to use this logic when
printing an Objective-C header for Clang's consumption. The mangled
names will always start with _Tt, so they're easy to recognize and
demangle in various tools or, eventually, in the Objective-C runtime.
The new test (test/IRGen/objc_mangling.sil) is the only test of this
behavior at the moment. The other test changes are due to the
centralized logic tweaking the names of internal constants (_DATA_*,
_CATEGORY_*, etc.).
This is the majority of <rdar://problem/15506580>.
Swift SVN r15588
When projecting an existential into an opened archetype, bind the
archetype with metadata and witness tables extracted from the
existential. Tweak SILGen so that it doesn't destroy the opened
archetype value an extra two times.
Use an executable testcase to ensure end-to-end operation, because we
still don't have a parsable form existential projection to opened
archetype instructions.
Swift SVN r13755
Refactor the base PolymorphicConvention implementation to work using generic signatures and dependent types instead of GenericParamLists and archetypes, using an ArchetypeBuilder to produce representative archetypes as a convenience when we need to consider all of the requirements attached to a dependent type. In EmitPolymorphicParameters, map the dependent types into context to resolve the archetypes that should be bound in the body of the function.
Swift SVN r13685
This lets us share implementation with emitArchetypeMethodValue and easily generalize emitArchetypeMethodValue to work with concrete types.
Swift SVN r10941
Handle an indirect cast from a class existential, so we can cast class existentials to opaque archetype types. Fixes <rdar://problem/15313840>.
Swift SVN r10545
Greg indicated that objc_getProtocol only works if somebody actually reifies a protocol_t record for the protocol with the runtime, so we need to emit our own protocol_t for every Protocol* value we do a checked cast with. Hijack the ClassDataBuilder to also build protocol_t records.
Swift SVN r9420
Use objc_getProtocol to derive a reference to the Protocol* for each required conformance, then pass the array off to a to-be-written dynamicCastObjCProtocol(Un)?Conditional entry point that will do all of the conformsToProtocol checks.
Swift SVN r9397
Replace the existing suite of checked cast instructions with:
- unconditional_checked_cast, which performs an unconditional cast that aborts on failure (like the former downcast unconditional); and
- checked_cast_br, which performs a conditional pass and branches on whether the cast succeeds, passing the result to the true branch as an argument.
Both instructions take a CheckedCastKind that discriminates the different casting modes formerly discriminated by instruction type. This eliminates a source of null references in SIL and eliminates null SIL addresses completely.
Swift SVN r8696
For dynamic generic types, this emits the sequence of operations to turn a value witness table template into a full, valid value witness table. For now, leave it stubbed out as empty, except for dynamic singleton unions, where we copy the size, flags, and stride from the lone element's table.
Swift SVN r8014
If a generic type has dynamic layout, the value witness table for its instances is dependent on its generic parameters for size and alignment. Instead of emitting a global symbol for the vwtable in these circumstances, embed the value witness table template in the generic metadata template so that both get instantiated in tandem by the runtime when the generic instance metadata is requested.
Swift SVN r7931
"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
When an existential's contained type is used as a generic parameter, unwrap the existential container and save its metadata and witnesses to be used as polymorphic arguments.
Our AST representation can't quite express the distinction between a type parameter being satisfied by the existential type itself from being satisfied by the existential's contained yet. I use a goofy heuristic where I assume a protocol type bound to a type variable with no requirements is satisfied by the protocol type itself; this covers all of the existing <T> (Slice<T>, T) cases that come up in the library, while enabling the <T:Foo> (T) cases. This hopefully addresses <rdar://problem/14470097> well enough to unblock library work until we get a solid AST representation of this difference.
Swift SVN r6352
Improve our representations of casts in the AST and SIL so that 'as!' and 'is' (and eventually 'as?') can share almost all of the same type-checking, SILGen, and IRGen code.
In the AST, we now represent 'as!' and 'is' as UnconditionalCheckedCastExpr and IsaExpr, respectively, with the semantic variations of cast (downcast, super-to-archetype, archetype-to-concrete, etc.) discriminated by an enum field. This keeps the user-visible syntactic and type behavior differences of the two forms cleanly separated for AST consumers.
At the SIL level, we transpose the representation so that the different cast semantics get their own instructions and the conditional/unconditional cast behavior is indicated by an enum, making it easy for IRGen to discriminate the different code paths for the different semantics. We also add an 'IsNonnull' instruction to cover the conditional-cast-result-to-boolean conversion common to all the forms of 'is'.
The upshot of all this is that 'x is T' now works for all the new archetype and existential cast forms supported by 'as!'.
Swift SVN r5737
Use the new swift_dynamicCastIndirect runtime functions to implement casts from opaque archetype and existential types to concrete types.
Swift SVN r5684
Just refer to "class archetypes" and "class protocols". Change 'isClassBounded' methods to 'requiresClass', which is a character shorter.
Swift SVN r5674
Provide a lowering for the DeinitExistential instruction to deallocate the buffer in an existential container with an uninitialized value, using its deallocateBuffer witness.
Swift SVN r5623
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
Represent protocol 'P.metatype' types using the type metadata of the contained metatype. Emit 'typeof' value witnesses for protocol types that project the existential container buffer and then call the 'typeof' witness for the contained value. Implement the SIL protocol_metatype instruction the same way.
You can't quite call static methods on protocols yet because protocol_method doesn't know how to look up static methods from an existential metatype yet.
This breaks references to protocol names—they will try to create an existential metatype that refers to the metadata of the protocol type itself, rather than to the metadata of a conforming type. <rdar://problem/13438779> would fix them.
Swift SVN r5033
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
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
The argument to archetype_method can be a metatype, so allow that. While we're here, implement lowering for AssociatedMetatypeInst, and fix initial bringup of SIL-IRGen so that polymorphic arguments get emitted into the entry point BB instead of a random other BB.
Swift SVN r4741
ArchetypeMethodInst, like ProtocolMethodInst, actually needs to be modeled as returning a thick function type, in order to represent the metadata parameter to the witness table function. With that change to SILGen, implement ArchetypeMethodInst IRGen.
Swift SVN r4688
Factor out the parts of GenProto's prepareExistentialMemberRefCall necessary to map to SIL's ProtocolMethodInst. Similar to ConstantRefInst, we map the ProtocolMethodInst to an incomplete CallEmission and emit the call when all curry levels have been applied.
Swift SVN r3794
Factor out the witness table initialization and projection logic from GenProto so that IRGenSIL can use it to implement the ProjectExistential and InitExistential instructions. Also map the CopyAddr and DestroyAddr instructions to value witness table calls so that value semantics on protocol values (and other address-only values) work. The added test compiles but doesn't run yet because invoking methods on a protocol value still requires implementing the ProtocolMethod instruction.
Swift SVN r3787
The IR generation for this conversion is different from
derived-to-base conversions, because converting from an archetype to
its superclass type means projecting the buffer and then performing
the conversion.
Swift SVN r3462
The motivations here are that (1) the parametric types
that actually need the 'self' argument don't necessarily
all want to do what tuples do and put the VWT relative
to the metatype at some definable offset and (2)
recovering type parameters from the metatype is much
better defined than also hopping some relationship back.
Plus this allows VWTs to be shared across instances of
generic types. Also, I'm going to need to add a VW
that takes a metatype, and consistency seems right here.
If keeping two values live is actually punishing, I
might have to reconsider this. But the VWT is at least
always recoverable from the metatype, so....
I ended up abstracting the thing that GenHeap was doing
in order to save archetypes for arrays, because I
needed it to save metatypes instead of VWTs and because
it really needed abstractin'.
Swift SVN r3096
to avoid some obvious redundancies. This also gives us a
more general framework with which to exploit other ways
in which metadata is known.
Swift SVN r3047
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
This is kindof a pain in a few places where the type system
doesn't propagate canonicality. Also, member initializations
are always direct-initializations and so are allowed to use
explicit constructors, which is a hole in our canonicality
tracking. But overall I like the idea of always working
with canonical types.
Swift SVN r2893
