Previously, we were creating the type corresponding to
class/struct/union declarations as part of creating the declaration
node, which happens at parse time. The main problem with this (at the
moment) occurs with nested nominal types, where we'd end up with the
wrong "parent" type when the type was nested inside an extension
(because the extension hadn't been resolved at the time we accessed
the parent's type). Amusingly, only code completion observed this,
because the canonical type system hid the problem. The churn in the
code-completion tests come from the fact that we now have the proper
declared type for class/struct/union declarations within extensions.
Take a step toward order-independent type checking by setting the type
of a class/struct/union declaration in type checking when we either
find the declaration (e.g., due to name lookup) or walk to the
declaration (in our walk of the whole translation unit to type-check
it), extending the existing TypeChecker::validateTypeDecl() entry
point and adding a few more callers.
The removeShadowedDecls() hack is awful; this needs to move out to the
callers, which should be abstracted better in the type checker anyway.
Incremental, non-obvious step toward fixing the representation of
polymorphic function types. This yak has a *lot* of hair.
Swift SVN r7444
Previously, TypeAliasDecl was used for typealiases, generic
parameters, and assocaited types, which is hideous and the source of
much confusion. Factor the latter two out into their own decl nodes,
with a common abstract base for "type parameters", and push these
nodes throughout the frontend.
No real functionality change, but this is a step toward uniquing
polymorphic types, among other things.
Swift SVN r7345
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
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
If a protocol requirement is satisfied by a generic method, we'll need to save the substitutions necessary to call that method from the witness thunk. This patch adds the spot in the ProtocolConformance::Mapping to save the substitutions; for now, always leave it empty and update the code for the type change.
Swift SVN r6399
Include methods from other contexts used to conform to an extension's declared objc protocol conformances in the category generated for that extension.
Swift SVN r5669
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
In the implementation of class-bounded archetypes and existentials, instead of referring to ObjC pointer types and retain/release operations directly, use an 'UnknownRefCountedPtrTy' and 'emitUnknownRetain/Release' functions.
Swift SVN r5619
Add overloads of getFragileTypeInfo and getFunctionType that take a SILType instead of a Swift CanType, and use them where it's easy to do so. Right now they just forward to the CanType versions, but we'll want to do SILType-specific type conversion soon. Clean up some IRGenSILFunction interfaces now that SILFunction carries most of the information IRGen needs intrinsically. No functionality change.
Swift SVN r5141
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
Find function bodies and emit their local type decls using the AST instead of relying on SILConstants to point the way back to the function bodies.
Swift SVN r4916
Change the destroying destructor entry point ABI to take 'this' as the appropriate type instead of as %swift.refcounted. Emit the deallocating destructor in IRGen when we see the ClassDecl, not when we see the SILFunction for the destructor. This frees us from having to worry about whether a SILFunction came from a destructor decl. We won't be able to reconstruct that once SILFunctions are pre-mangled.
While we're here, repaint some bikesheds so it's clearer that SIL and SILGen work with the destroying destructor.
Swift SVN r4908
ObjC classes don't have a deallocating destructor, so we can't call up to it in a class derived from an ObjC class. Hack SILGen not to emit a call to the superclass destructor of a class inherited from an ObjC class. This is the wrong thing, but it looks like destructors don't get hooked up to ObjC dealloc methods anyway yet, so what the Swift destructor of an ObjC-derived class does is moot right now. This lets us remove the guards from IRGen that prevented ObjC destructors from being emitted.
Swift SVN r4784
Teach SILGen how to emit the implicit elementwise constructor for structs and the implicit default constructor for classes, and eliminate the now dead IRGen code for them. Add a StructInst SIL instruction to represent constructing a loadable struct value from elements, analogous to TupleInst for tuples.
Swift SVN r4778
