can often produce an lvalue, for everything else it produces an RValue.
Split it up a bit so that all of the lvalue cases are handled by
emitLValueForDecl (which it calls). This allows clients that only
expect an lvalue back to have a simpler path, and allows one that
wants to probe to see if something is an lvalue or not to be simpler.
Swift SVN r12715
use the new RValue emission infrastructure instead of duplicating
some of it. This enables the use of computed properties, fixing
<rdar://problem/15859432> SILGen abort when pattern matching on computed property
and eliminates some code that future changes would otherwise have to
worry about.
There are other problems with this code (e.g. see rdar://15863069), so I think
we should disable the feature until it has time to really bake, but this is still
useful progress in the right direction and is a net reduction of code.
Swift SVN r12618
use emitReferenceToDecl when we expect an lvalue or rvalue. This
makes the code more explicit and avoids duplicating the "emit a
load if emitReferenceToDecl returned an lvalue" logic.
Swift SVN r12603
instead of a ValueDecl (which is more specific). This allows them to
use the more specific ASD::usesObjCGetterAndSetter() method instead
of SGM::requiresObjCDispatch.
To enable this, push AbstractStorageDecl through SILGenLValue's
GetterSetterComponent.
Swift SVN r12578
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
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
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
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
- 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
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
properties are represented as rvalues, not non-mutable lvalues. As part of
this, isReferencedAsLValue() only returns true for mutable VarDecls.
This required some pretty serious rearrangement and refactoring of code,
because now (among other things) get-only properties can be emitted as rvalues,
so the rvalue machinery needs to be able to produce getter calls.
This is an important step towards getting proper value semantics going (for
'let's etc) and also allows us to materialize addresses less often. As a
simple example, before we would silgen this:
struct S {
var i : Int
}
var P : S { get: ... }
func f() {
print(P.i)
}
into:
%2 = function_ref @_TF1tg1PVS_1S : $@thin () -> S // user: %3
%3 = apply %2() : $@thin () -> S // user: %5
%4 = alloc_stack $S // users: %9, %6, %5
store %3 to %4#1 : $*S // id: %5
%6 = struct_element_addr %4#1 : $*S, #i // user: %7
%7 = load %6 : $*Int64 // user: %8
now we generate:
%2 = function_ref @_TF1tg1PVS_1S : $@thin () -> S // user: %3
%3 = apply %2() : $@thin () -> S // user: %4
%4 = struct_extract %3 : $S, #i // user: %5
Swift SVN r11632
only handle rvalues. Clients that can either have an lvalue or an rvalue (which
are few, and will be diminishing as other planned changes happen like the tuple
vs argument split) use a specific api to indicate such.
Swift SVN r11572
Reuse John's abstraction thunking machinery in SILGenPoly to emit the abstraction change from a protocol requirement to a concrete witness. There are potentially two abstraction changes necessary; if a witness is generic, we need to reabstract again from the concrete substituted type of the witness to the generic witness function's original signature. This currently leads to a bunch of extra temporaries in cases where an argument or return gets unabstracted to a loadable value then reabstracted to a generic parameter, but optimizations should be able to clean this up. Protocol witnesses also have additional potential abstraction changes in their 'self' parameter: the 'self' parameter of the protocol requirement is always considered @inout, but class 'self' parameters are not; also, an operator requirement can be satisfied by a free function, in which case 'self' is discarded.
Also, fix a bug in return value thunking where, if the thunk could reuse its @out parameter as the @out parameter of the underlying function, we would not disable the cleanup we install on the result value, leading to the result getting overreleased.
Swift SVN r11245
- change SILGenFunction to use Cleanup and Implicit return locations for
auto-generated cleanups/returns where sensible.
- Fix a bug in where ConstructorDecl that would return the wrong
source range.
- Move the expected locations of some errors to the end of the function
where they should belong.
Fixes <rdar://problem/15609768> Line tables for classes that don't have
init but just initialize ivars are odd
Swift SVN r11086
This gives more predictable semantics for initializers and destructors under the DI model, and also unblocks enabling the DI model at all for @objc initializers. <rdar://problem/15614052>
Swift SVN r11029
is used for VarDecls that are immutable once defined. This
will eventually be used to model 'val' in SILGen, but for now
we can use it to optimize some 'self' situations.
At present, we use it for class 'self' in destructors and for
init methods of root classes. The init methods of derived
classes need to be able to mutate self when calling super.init
so they can't use this presently. I haven't gotten around to
switching general methods to use it yet.
This introduces two new regressions that don't appear in the
testsuite: we lose debug info for "self" in this case, and
we cannot close over self.
Swift SVN r10962
