Add __FUNCTION__ to the repertoire of magic source-location-identifying tokens. Inside a function, it gives the function name; inside a property accessor, it gives the property name; inside special members like 'init', 'subscript', and 'deinit', it gives the keyword name, and at top level, it gives the module name. As a bit of future-proofing, stringify the full DeclName, even though we only ever give declarations simple names currently.
Swift SVN r14710
Inherited initializers are now functional: one can use an inherited
initializer to construct an object of a subclass type, and we properly
handle delegation to overridden complete object or subobject
initializers as appropriate. See the executable test.
This commit also contains various fixes for the IRGen side of vtable
emission and use. Proper IRGen tests still to come.
For now, we're still performing peer delegation from a subobject
initializer to another subobject initializer, hence the SILGen hack
for identifying when we're in a complete object vs. a subobject
initializer. We'll be banning delegation from subobject initializers,
so this hack---along with the peer_method instruction---will be going
away in the near future.
Swift SVN r14571
These changes add support for build and target configurations in the compiler.
Build and target configurations, combined with the use of #if/#else/#endif allow
for conditional compilation within declaration and statement contexts.
Build configurations can be passed into the compiler via the new '-D' flag, or
set within the LangOptions class. Target configurations are implicit, and
currently only "os" and "arch" are supported.
Swift SVN r14305
When projecting an existential into an opened archetype, bind the
archetype with metadata and witness tables extracted from the
existential. Tweak SILGen so that it doesn't destroy the opened
archetype value an extra two times.
Use an executable testcase to ensure end-to-end operation, because we
still don't have a parsable form existential projection to opened
archetype instructions.
Swift SVN r13755
- Add a "isDirectPropertyAccess" bit to DeclRefExpr, serving the
same purpose as MemberRefExprs for non-member properties.
- Teach sema to synthesize correct non-member get/set implementations
for observing properties.
- Teach silgen to handle the isDirectPropertyAccess bit.
Swift SVN r13600
- purge @inout from comments in the compiler except for places talking about
the SIL argument convention.
- change diagnostics to not refer to @inout
- Change the astprinter to print InoutType without the @, so it doesn't show
up in diagnostics or in closure argument types in code completion.
- Implement type parsing support for the new inout syntax (before we just
handled patterns).
- Switch the last couple of uses in the stdlib (in types) to inout.
- Various testcase updates (more to come).
Swift SVN r13564
This patch:
- Changes sema to set the "IsDirectPropertyAccess" on MemberRefExprs
in inits/destructors that should be done directly because they are
on the local object.
- Removes the "SGF.AlwaysDirectStoredPropertyAccess" bool in SILGen,
which was the source of the problem above and was otherwise problematic.
This will get a bit simpler when -enable-new-objc-properties rolls out.
Swift SVN r12967
If all of the bindings in a pattern column are 'let' bindings, don't box the binding. If there is any 'var' in the column, conservatively fall back to binding a box. Factor out the logic for producing an initialization for a variable into an new emitInitializationForVarDecl method that SILGenPattern can use. Add a 'copyInto' method to RValue that can bind a copy of an rvalue to an Initialization.
This doesn't use Chris's new +0 ManagedValue optimization yet, so we end up with an extra copy_value when the value is bound that might still be avoidable.
Swift SVN r12903
- Remove my previous local hack.
- Add a new flag to SGFContext indicating that clients are ok with +0 rvalues.
- Teach emitRValueForPropertyLoad and emitRValueForDecl how to work with +0 rvalues.
This allows us to avoid retaining bases in arbitrarily nested struct rvalue
member_ref_expr's. For example, this:
class SomeClass {}
struct AnotherStruct {
var x : Int
var c : SomeClass
}
struct StructMemberTest {
var c1 : SomeClass, c2 : SomeClass
var s : AnotherStruct
func testRecursiveStruct() -> Int {
return s.x
}
}
used to compile to:
sil @_TFV1t16StructMemberTest19testRecursiveStructfS0_FT_Si : $@cc(method) @thin (@owned StructMemberTest) -> Int64 {
bb0(%0 : $StructMemberTest):
debug_value %0 : $StructMemberTest // let self // id: %1
%2 = struct_extract %0 : $StructMemberTest, #s // user: %3
%3 = copy_value %2 : $AnotherStruct // users: %5, %4
%4 = struct_extract %3 : $AnotherStruct, #x // user: %7
destroy_value %3 : $AnotherStruct // id: %5
destroy_value %0 : $StructMemberTest // id: %6
return %4 : $Int64 // id: %7
}
and now it compiles to:
sil @_TFV1t16StructMemberTest19testRecursiveStructfS0_FT_Si : $@cc(method) @thin (@owned StructMemberTest) -> Int64 {
bb0(%0 : $StructMemberTest):
debug_value %0 : $StructMemberTest // let self // id: %1
%2 = struct_extract %0 : $StructMemberTest, #s // user: %3
%3 = struct_extract %2 : $AnotherStruct, #x // user: %5
destroy_value %0 : $StructMemberTest // id: %4
return %3 : $Int64 // id: %5
}
There is more that can come from this, but it is a start. This cuts out 50 retain/release pairs from the stdlib.
Swift SVN r12857
- Strength reduce the interface to LogicalPathComponent::getMaterialized
to now just return a SILValue for the address. The full "Materialize"
structure hasn't been needed since MaterializeExpr got removed.
- Move 'struct Materialize' out of SILGen.h into SILGenLValues.cpp now
that it is only used for logical property materialization.
- Drop the dead 'loc' argument on DeallocStackCleanup. The location is
already specified when the cleanup is emitted.
Swift SVN r12827
in memory of the available type is address only, so simplify a check and
remove the predicate (which happens to be out of date anyway).
Swift SVN r12814
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
