When applying getInheritedConformance to a specialized conformance, reapply the specialization to the found inherited conformance so we get a conformance for the same type we put in, making the specializer's job easier when finding conformances to insert into archetype_methods. To expose the problems this fixes, add a check in the SIL verifier that ArchetypeMethodInsts carry a ProtocolConformance that actually matches their lookup type.
Swift SVN r12988
properties have accessors, we have an amazing property: everything that we
want to form a getter or setter for ... really has one! I suspect many things
can be simplified now, but the first on the chopping block is
StorageDecl::getGetterType (and its three friends) which is now always exactly
just getGetter()->getType().
Swift SVN r12983
This method looks recursively through the operand chain of the given SILValue
until it finds a non-object projection instruction. It then returns that value.
An object projection instruction is one of:
1. struct_extract.
2. tuple_extract.
Swift SVN r12918
An address projection instruction is one of the following instructions:
1. struct_element_addr.
2. tuple_element_addr.
3. ref_element_addr.
This method takes in the given SILValue and continually searches up its
operand chain until it finds a non address projection, non-cast
value (where cast is defined as in SILValue::stripCasts()). The found
SILValue is then returned.
Swift SVN r12909
This method takes in a SILValue and returns the SILValue created by continually
moving up the operand chain of the SILValue until a non-cast instruction is hit.
The non-cast instruction is then returned.
Swift SVN r12906
Even if the type is the DeclaredTypeInContext of the nominal, we still want the substitution list for generic specialization. Ideally the AST would always have a SpecializedProtocolConformance when we refer to a generic type instance, but our representation makes that difficult.
Swift SVN r12887
This mimics what we do for ConstructorDecls, and all of the callers
already DTRT here. Fixes the first half of <rdar://problem/15883734>.
Swift SVN r12811
with two kinds, and some more specific predicates that clients can use.
The notion of 'computed or not' isn't specific enough for how properties
are accessed. We already have problems with ObjC properties that are
stored but usually accessed through getters and setters, and a bool here
isn't helping matters.
NFC.
Swift SVN r12593
Lower types for SILDeclRefs from the interface types of their referents, dragging the old type along for the ride so we can still offer the context to clients that haven't been weaned off of it. Make SILFunctionType's interface types and generic signature independent arguments of its Derive the context types of SILFunctionType from the interface types, instead of the other way around. Do a bunch of annoying inseparable work in the AST and IRGen to accommodate the switchover.
Swift SVN r12536
We need to model the difference between Objective-C- and Swift-rooted
class hierarchies in SIL. IRGen is too late to handle nil returns.
This reverts commit 549db981ea0136a67aee3029aefe18a05d3c8833.
Swift SVN r12400
No functional difference from the unconditional checked downcast we
had before, but this gives IRGen the chance to specialize the
implementation.
Swift SVN r12382
When we decide to emit a separate ivar initializer method (via the
Objective-C entry point -.cxx_construct), we no longer initialize the
ivars within the initializer. This only happens for derived classes,
so teach DI about uninitialized 'self' values that require a
super.init call but don't require the ivars to be initialized.
Swift SVN r12240
When we're using Objective-C's memory allocation, emit .cxx_construct
methods whenever we have instance variables with in-class
initializers. Presently, these methods are just empty stubs.
Swift SVN r12211
The Objective-C runtime executes the .cxx_destruct method after the
last -dealloc has executed when destroying an object, allowing the
instance variables to remain live even after the subclass's
destructor/-dealloc has executed, which is important for memory
safety. This fixes the majority of <rdar://problem/15136592>.
Note that IRGenModule::getAddrOfIVarDestroyer() contains an egregious
hack to find the ivar destructor SIL function via a linear
search. We need a better way to find SIL functions that we know exist,
because LinkEntity does not suffice.
Swift SVN r12206
give 'let' declarations debug info. This is part of rdar://15785053.
IRGen is just stubbed out and nothing generates these yet (other than
the sil parser).
Swift SVN r12179
Because Objective-C doesn't have the notion of a destroying
destructor, this is a matter of cleanliness rather than
correctness. Still, it's better not to lie.
Swift SVN r12160
Note that this lowering currently assumes that the static type of the class is its dynamic type. This should be a flag on the dealloc_ref instruction, not an assumption.
Swift SVN r12144
SILDeclRef was previously storing the ClassDecl for this case, because
semantic analysis didn't guarantee that a DestructorDecl was always
present. It is now, and this representation makes more sense.
Swift SVN r12122
Teach SILGen to emit a -dealloc method that runs user code, destroys
instance variables, and then calls up to the superclass dealloc. Teach
IRGen to deal with Objective-C destructor methods and add -dealloc to
the instance method table.
There are a few things still wrong here: we're emitting both a Swift
destructor and -dealloc, even though only one of them should ever
actually be used. Additionally, instance variables shouldn't be
destroyed in -dealloc, but in .cxx_destruct, so they persist until the
last of the -dealloc methods is invoked.
Swift SVN r12115
General compiler support is missing for 'type' properties on classes, and lets don't
work either, but at least we have a nice diagnostic now.
also, rename static -> type in a few internal diagnostic names.
Swift SVN r12102
In general, this forces SILGen and IRGen code that's grabbing
a declaration to state whether it's doing so to define it.
Change SIL serialization to serialize the linkage of functions
and global variables, which means also serializing declarations.
Change the deserializer to use this stored linkage, even when
only deserializing a declaration, and to call a callback to
inform the client that it has deserialized a new entity.
Take advantage of that callback in the linking pass to alter
the deserialized linkage as appropriate for the fact that we
imported the declaration. This computation should really take
advantage of the relationship between modules, but currently
it does not.
Swift SVN r12090
