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
SIL instruction. Implement IR-gen support for same. Fix
the parsing of SIL string literals to properly unescape them.
SIL-gen still emits UTF8 literals unconditionally.
Swift SVN r11904
- Change the AST for get/set functions to take self @inout only when they
are @mutating. Setters default to @mutating, but can be explicitly marked
@!mutating. Getters default to not mutating, but can be marked @mutating.
This causes self to follow.
- Change sema to handle semantic analysis of a.y (and subscripts) based on
whether the computed type of a allows mutation (which is when 'a' is an
lvalue, or both the getter and setter are non-mutating). When both of
these conditions fail, 'a.y' has rvalue type, and is thus non-mutable.
- Rework silgen of lvalues to handle this: now properties and subscripts
can have rvalues as bases, which means that all the lvalue machinery needs
to be able to handle the full generality of base expressions (which is
what my recent patches have been paving the way towards).
- Rework silgen of rvalues to similarly handle rvalue bases.
- Rework silgen of both to handle the case where the AST has found a base
expression that is an lvalue, but where only a non-mutating getter or
setter is needed. Right now, we just emit a load of the lvalue, but
it would result in better code to not require the base be an lvalue at
all (todo).
The upshot of all of this is that we are doing *much* less AST-level
materialization (MaterializeExpr goes down), we generate a lot better SIL
out of SILGen in many cases, and 'self' being an rvalue in properties and
subscripts means that we correctly reject code like the examples in
test/Sema/immutability.swift.
Swift SVN r11884
making LValue ManagedValues, and switch SILGenLValue to use
this form of managed value consistently for lvalues, instead of
using unmanaged values in some cases. NFC.
Swift SVN r11878
the things that apparently care about it. The LValue/RValue machinery is
happy to pass around the VarDecl/SubscriptDecl for the entity being
referenced, and this simplifies things.
Swift SVN r11857
not as part of the lvalue path. This means that the arguments to a
function (for example) are always rvalues - @inout arguments are not a
special case all over the place.
This removes emitLValueOrRValueAsRValue and emitLValueAsRValue, because
the lvalue that both of them were trying to handle was @inout, not @lvalue.
Swift SVN r11805
I originally wrote to turn "loadexpr(declrefexpr(letdecl))" is dead, remove
it. Let decls are now always rvalues, so they never are loaded.
Swift SVN r11804
is no longer an lvalue, since it doesn't make sense to assign to super.
This eliminates a bunch of special cases and simplifies things.
Swift SVN r11803
- Introduce a new TypeBase::getInOutObjectType() that strips off @inout types
- Switch stuff that is calling getRValueType() to call getInOutObjectType()
when they are stripping @inout, not @lvalue (this is primarily around
stuff working with self)
- Update testcases, some diagnostics improve around & handling.
This fixes rdar://15708430 and rdar://15729093.
Swift SVN r11794
This allows them to appear in argument lists of functions, enabling behavior
like this:
func test_arguments(a : Int, var b : Int, let c : Int) {
a = 1 // ok (for now).
b = 2 // ok.
c = 3 // expected-error {{cannot assign to the result of this expression}}
}
Swift SVN r11746
