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
What we actually do here will likely change depending on how we want
to handle error propagation in general, but for now it suffices to
propagate the nil via an early exit.
Swift SVN r12440
Swift-rooted class hierarchies don't permit the replacement of "self",
so it's guaranteed that the 'self' returned from a 'super.init'
invocation is identical to the previous self. Elide the unconditional
checked downcast (that manifests as a call to
swift_dynamicCastClassUnconditional in the runtime) by putting in the
moral equivalent of a bitcast.
For Objective-C-rooted hierarchies, 'self' can be replaced, so memory
safety dictates that we use the unconditional checked downcast. Note
that this path is still unsafe against nil returns.
Swift SVN r12401
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
- constify the Initialization::getAddressOrNull/hasAddress functions.
- Teach the initialization logic that 'let' initializations can be
split into tuple subelements by address (i.e. i
getSubInitializationsForTuple works on them) when the let decl has
a backing memory allocation.
- Teach LetValueInitialization to produce a backing memory object
for address-only tuple arguments, since they are passed as multiple
SILArguments and need some place in memory to reassemble them.
The collection fixes a bad miscompilation where the RValue logic emitted
a temporary (through getSingleValue) which we then accidentally lifetime
extended for the duration of the argument. This led to bad things when
the temporary got destroyed too early.
Thanks to MichaelG for helping narrow down this problem, it initially looked
like a sil optimizer bug.
Swift SVN r12234
When a class that will be allocated by the Objective-C runtime also
requires all of its stored properties have initial values, move that
complete initialization of the object into -.cxx_construct, which is
invoked by the runtime after +alloc.
Definite initialization doesn't like the resulting initializers (which
don't initialize any of their ivars) at all, so no end-to-end testing yet.
Swift SVN r12229
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
The Swift entry point is required for the Swift metadata, while the
Objective-C entry point goes into the Objective-C metadata. As part of
this, stop emitting the destroying destructor for classes that use
Objective-C allocation: it won't work anyway.
Swift SVN r12199
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
We use Objective-C allocation for classes whose root was defined in
Objective-C. Any Swift class whose root is defined in Swift will use
Swift's allocation routines instead.
Plus some minor cleanup in advance of implementing -dealloc.
Swift SVN r12104
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
This is the dual of our initialization story: delay the destruction of
instance variables until after the execution of the superclass
destructor, so that memory safety is preserved even if the superclass
destructor calls a method on teh subclass.
Swift SVN r12089
lvalues. (They're all addresses.) We need to
mark the resulting ManagedValues as lvalues as
well, so that SILGen emits loads for them
correctly.
Swift SVN r12066
In nongeneric contexts, or contexts where we only care about the indirectness of parameters or have already substituted the generic parameters for a function, the interface types are interchangeable, so just switch over.
Swift SVN r12044
Make the compiler fully support both UTF-8 and UTF-16 string
literals. A (standard-library-defined) string type (such as String)
that wants UTF-16 string literals should conform to the
BuiltinUTF16StringLiteralConvertible protocol; one that wants UTF-8
string literals should conform to the BuiltinStringLiteralConvertible
protocol.
Note that BuiltinUTF16StringLiteralConvertible inherits from
BuiltinStringLiteralConvertible, so a string type that wants UTF-16
string literals also has to implement support for UTF-8. The UTF-16
entry point is preferred when the compiler knows that UTF-16 is
supported. This only tends to happen when we have a generic parameter
that is required to conform to StringLiteralConvertible, e.g.,
func f<T: StringLiteralConvertible>() {
var t: T = "Hello, World!" // uses UTF-8 entry point
}
because the UTF-8 entry point is the only one guaranteed to be available.
Swift SVN r12014
Emphasize the fact that this address is only intended for initialization. When we split destructive_switch_enum_addr, there will be another similar instruction for destructively taking the payload out of an already-initialized enum.
Swift SVN r12000
Treat the interface types of SILFunctionTypes as the canonical representation in the verifier. Do a bunch of supporting and annoyingly irreducible work to enable this:
- Stop trying to uncurry generic parameter lists during type lowering and preserve the structure of AST GenericParamLists. This makes mapping dependent types into contexts easier.
- Properly walk generic parameter lists at all depths when grooming substitution vectors for use with substGenericArgs interfaces.
- Reseat the generic parameter lists created for protocol_method results so that we don't expect the outer Self archetype to be unbound; it's provided by the extra data of the result.
- Hack SILFunctionType serialization never to use a decl reference when serializing its generic param list. When this happens, we get incorrect archetypes. This is a gross hack, but when we're able to jump all the way to interface types, it can go away.
Putting these ducks in a row nicely un-XFAILs TextFormatting.swift.
Swift SVN r11989
While we're here, cache the result of looking for delegation or
chaining calls within ConstructorDecl. Only Sema and SILGen for the
body of the constructor care, so we don't serialize this
information. Rather, we have a faster-path to recompute it should
someone ask again after it was cached.
Swift SVN r11969
As with chaining initialization ('super.init' calls), wrapping the
delegating initialization in RebindSelfInConstructorExpr ensures that
'self' gets overwritten by the result of delegation.
Note that I'd much prefer that RebindSelfInConstructorExpr be
introduced by the type checker (not the parser). That cleanup will
follow.
Swift SVN r11932
