The current implementation of dealloc_stack in IR-gen is a
no-op, but that's very much wrong for types with non-trivial
local allocation requirements, e.g. archetypes. So we need
to be able to do non-trivial code here. However, that means
modeling both the buffer pointer and the allocated address
in SIL.
To make this more type-safe, introduce a SIL-specific
'[local_storage] T' type that represents the required
allocation for locally storing a T. alloc_stack now returns
one of those in additon to a *T, and dealloc_stack expects
the former.
IR-gen still implements dealloc_stack as a no-op, but
that's now easy to fix.
Swift SVN r6937
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
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
The idea for now is that this is a SIL-only type used for
representing the storage of a weak or unowned reference.
Having it be its own type is pretty vital for reasonable
behavior in SIL and IR-generation, and it's likely that
this will surface into runtime metadata as well (hence
the mangling).
I've implemented a bunch of things that technically I don't
think are necessary if this stays out of the typechecker,
but it's easier to implement half-a-dozen "recurse into
the child type" methods now that it would be to find them
all later if we change our minds.
Swift SVN r6091
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
Just refer to "class archetypes" and "class protocols". Change 'isClassBounded' methods to 'requiresClass', which is a character shorter.
Swift SVN r5674
If an archetype has a superclass bound, we can assume the superclass's
retain semantics for the type. We can also use the superclass's storage pointer type to cut down on some bitcast IR noise when calling superclass methods on the archetype value.
Swift SVN r5642
Treat archetypes with a superclass bound as class-bounded. Change SILGen and IRGen to use the new SuperToArchetypeRef and ArchetypeRefToSuper cast instructions, and drop the old SuperToArchetype and ArchetypeToSuper instructions, which are unneeded because any archetype with a superclass will be class-bounded.
Note that this patch doesn't implement representation optimization for archetypes with superclass bounds--they're still always represented with a worst-case UnknownRefCountedPtrTy.
Swift SVN r5629
Split ArchetypeTypeInfo into ClassBoundedArchetypeTypeInfo, for class-bounded archetypes, and OpaqueArchetypeTypeInfo, for fully generalized archetypes (the existing case). ClassBoundedArchetypeTypeInfo is represented using a single refcounted ObjCPointer. Implement abstraction remapping from class instances to class-bounded archetypes and back, and from class-bounded archetypes to non-class-bounded and back.
Witness tables are still generated only for opaque archetypes, so method calls on class-bounded archetypes won't work just yet.
Swift SVN r5569
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
seems that this is not a good idea, because it seems statically live from the SIL
SuperToArchetypeInst. However, apparently nothing in the testsuite exercises
this code, so I'll need to discuss and a testcase to know how much logic needs
to be ressurrected from SVN. rdar://13681541
Swift SVN r4800
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
protocol witnesses over to the new API. There's some badness
that we're papering over here involving generic types, but
this is a necessary first step.
Swift SVN r3003
the metadata objects for classes. This is currently only
done for methods defined in the main class body, and it's
(naturally) totally fragile, and it's screwed up in a
couple known ways w.r.t. generic classes: there's no
thunking when the overrider differs by abstraction from
the overridden method, and methods on classes currently
expect to get all the type arguments passed directly
and thus will disagree in signature from members of
non-generic classes. Also, of course, we're not using
any of this in the call infrastructure. But it's progress.
Swift SVN r2901
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
