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
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
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
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
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
For a witness to a generic requirement, the generic parameters of the requirement should be parented to the generic parameters of the conformance, not to the 'Self' parameter list of the original protocol. The generic signature conversion in SILFunctionType construction revealed this improper nesting because it was introducing unused "$T_0_0" parameters into witnesses in nongeneric conformances.
Swift SVN r11861
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
with qualifiers on it, we have two distinct types:
- LValueType(T) aka @lvalue T, which is used for mutable values on the LHS of an
assignment in the typechecker.
- InOutType(T) aka @inout T, which is used for @inout arguments, and the implicit
@inout self argument of mutable methods on value types. This type is also used
at the SIL level for address types.
While I detangled a number of cases that were checking for LValueType (without checking
qualifiers) and only meant @inout or @lvalue, there is more to be done here. Notably,
getRValueType() still strips @inout, which is totally and unbearably wrong.
Swift SVN r11727
being closed over. If we allowed arguments to have tuple type
in the SILFunctionType type system, this would just work. As it is,
we have to do a bit of [re|de]structuring on the partial_apply and
the closure body side to work things out.
Swift SVN r11680
We should be able to cut out another layer of IRGen grime now.
This does XFAIL one test, test/Prototypes/TextFormatting.swift, which fails because of a weird archetype ordering in a nested substitution list. This should get sorted out by switching to interface types, so I'm going to let it go until then.
Swift SVN r11618
We'll need to perform name lookup based on the file-level
DeclContext*, so the module no longer suffices. No functionality
change here yet.
Swift SVN r11523
emit the cleanup for the initializing expression when the expression was
complete, instead of at the end of the let decl scope (releasing things
too early).
This fixes rdar://15689514, thanks to DaveA for the great testcase.
Swift SVN r11516
(various) FunctionType::get's, ArrayType::get,
ArraySliceType::get, OptionalType::get, and a few
other places.
There is more to be done here, but this is all I plan to do
for now.
Swift SVN r11497
as values, without a box at all. This generalizes some of the
previous hacks I had for silgen'ing 'self' as a value instead of
a box, and capturing them with CaptureKind::Constant.
Swift SVN r11360
allocating a box for them. When self is not marked inout (which will be
the default for structs someday) it changes the codegen of:
struct Foo {
...
func testfunction() -> Foo {
return self
}
}
To:
sil @_TV1t3Foo12testfunctionfS0_FT_S0_ : $@cc(method) @thin (Foo) -> Foo {
bb0(%0 : $Foo):
%1 = tuple ()
return %0 : $Foo // id: %2
}
instead of allocating a box, doing a store to it, etc.
Also included: don't maintain references into VarLoc where a simple copy
of the element would suffice. This isn't important, but was part of my
silvtable debugging and seems like the right thing.
Swift SVN r11307
A SpecializedProtocolConformance intentionally contains all of the
information we need to synthesize the type witnesses from the
underlying (generic) conformance. Do so lazily rather than eagerly,
because we won't always need all of them.
As a nice side effect, we no longer need to serialize the witnesses of
these specialized protocol conformances, so we can save some space in
the Swift module file.
Swift SVN r11303
Tweak the type lowering code to work when the conforming type is generic. Handle the case of an associated type with protocol requirements being witnessed by an archetype of the conforming type, which results in a null ProtocolConformance pointer in the witnessing substitution.
Swift SVN r11275
In doing so, make serialization more deterministic. It was depending
on DenseMap ordering for both type and value witnesses. Now, serialize
the witnesses in the declaration order of the requirements.
Swift SVN r11267
When a type conforms to a protocol that refines another protocol, emit the witness table for the base protocol, and drop a reference into the witness table for the derived protocol. Keep track of what conformances we've already emitted so we don't emit redundant witness tables when types conform redundantly to base protocols or have multiple references to a base protocol via a refinement diamond.
Swift SVN r11263
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
Walk the ProtocolConformances of type and extension decls to produce SILWitnessTables for them. Work out the type of the witness function by applying substitutions from the witness map and lowering it at the abstraction level of the requirement, then emit a symbol for the witness function (but don't emit the body of the witness function just yet).
Swift SVN r11143
are not settable (like get-only ones). Set the 'isLet' bit in various
places, but not the particularly interesting or useful places yet.
Swift SVN r11121
