Generate ConstructorDecl bodies, sandwiched between code to allocate an instance before running the body and code to return the initialized value afterward. Still need to:
- handle the implicit constructor for structs
- divide the class constructor into allocating and initializing entry points
- chain a call to the base class initializer entry point from the derived class initializer
Swift SVN r3662
Generate explicit destructors by emitting their bodies then emitting release sequences for the class's members. Eventually we'll need to also emit implicit destructors for classes without explicit destructors and to chain a call to the base class destructor, which will require adding a new linkable entity flag onto SILConstant for destructors, similar to getter/setters.
Swift SVN r3655
Add an instruction to represent super-to-archetype downcasts. Since archetypes are address-only, it needs to take a reference to the destination archetype as a parameter.
Swift SVN r3643
Invoke the leaf destructor for the Instruction when it's eraseFromParent-ed, so that the SILSuccessors of BranchInsts get updated when branches are removed. This un-breaks the peepholing of breaks out of else blocks.
Swift SVN r3641
We never actually invoke destructors on SIL Instructors, so the nice SILSuccessor RAII thingy in BranchInsts never kicks in to fix up predecessor lists when we erase BranchInsts. Disable the code in Condition::exitFalse that tries to merge terminated else blocks and triggers an assert because of stale predecessor info. After the break I'll look into making Instruction::eraseFromParent actually perform some sort of instruction-specific cleanup.
Swift SVN r3592
Passing around internal references to a hashed container--not the best idea. Allocate TypeInfos from a bump allocator so they have fixed addresses and stash the pointers in the type map. While we're here, simplify the FragileElement interface a bit by making it take ValueDecls directly as keys instead of identifiers.
Swift SVN r3590
Associated types still (correctly) manifest as GenericMemberRefs of the metatype. Use the new AssociatedMetatypeInst to represent getting an associated metatype from a generic.
Swift SVN r3589
If a function has an address-only return and a single non-tuple argument, then it's valid to have a two-argument call where the first argument matches the function input type and the second matches the result type. This occurs for instance if you try to call Builtin.load, with type Builtin.RawPointer -> T, for an address-only T.
Swift SVN r3587
Checking the result type of the FunctionType for address-only-ness doesn't work for a curried func decl, whose result type is a function type. Pass down the result type from the func decl to emitProlog instead of letting emitProlog derive it from the expr type.
Swift SVN r3586
Provide a temporary lame implementation of tuple initialization in emitExprInto so we can reenable the decls tests and fix up some other things before fully implementing in-place initialization.
Swift SVN r3585
Add some private per-recursion-level info that will let SILGen track emit-into initializations, materializing into a load, and other peephole optimizations. We'll also need context to be able to distinguish argument tuples from tuple values, which need to lower differently when they contain address-only elements.
Swift SVN r3579
ArchetypeMethodInst was still trying to cast to LValueType rather than checking the address-ness of the SIL type, and ApplyInst was failing for an address-only byref argument. This makes the last disabled expressions test pass again.
Swift SVN r3577
Prepare to do variable and return value initialization the smart way, by allocating the buffer first and then emitting the expression result directly into the buffer rather than by evaluating the expression then allocating and initializing the buffer. Create an Initialization class hierarchy that represents an uninitialized buffer or tuple of uninitialized buffers, and rewrite the argument and pattern binding logic to allocate and build up an Initialization first then emit the expression into it. The "emit into" part still needs to be implemented, as does tuple pattern binding ('var (a,b,c) = ...'). Disable some decls test that do tuple binding for now.
Swift SVN r3574
Address-only values are supported well enough now as assignment and function arguments that SILGenLValue::visit*MemberRefExpr doesn't need to weed them out anymore. This lets us re-enable some more checks in the expressions and properties tests.
Swift SVN r3572
Doug fixed the AST representation of type variable metatypes in r3532, so we don't need to check for bugged-out GenericMemberRef-to-metatype nodes anymore.
Swift SVN r3570
Now that we can represent address-only values, SILGen can correctly generate these operations in terms of archetype/existential addresses instead of impossible values. archetype_to_super is slightly tricky since we can forward ownership from the address-only derived value to the loadable base value, which is normally prevented by the ManagedValue interface, so I wrote some special-case logic directly into visitArchetypeToSuperExpr to handle forwarding the cleanup. Reenable some disabled checks in the expressions test for things that work again.
Swift SVN r3566
Needed to represent deinitializing a partially-initialized existential in which the value witness table has been populated by alloc_existential but the value has not been initialized yet.
Swift SVN r3565
The result of an address-only returning ApplyInst is going to be empty tuple, not the address-only type. Oops. Rearrange the logic so that it checks that an empty-returning ApplyInst for a non-empty-returning function actually has an address-only indirect return argument.
Swift SVN r3563
Emit global accessors as type '() -> [byref] T' instead of '() -> [byref(heap)] T' so that the SIL verifier doesn't stumble on unequal LValueTypes.
Swift SVN r3561
Refactor the assignment implementation a bit so that the FullExpr scope for the assignment lasts long enough that we can pass the ManagedValue from the right-hand side down into the visitor for the left-hand side. A physical assignment of an address-only temporary can take the temporary, but a logical assignment involving a setter call does not, so hand the ManagedValue down through emitAssignToLValue and LValue LogicalComponent::storeRValue so forward-ing can do its thing where appropriate.
Swift SVN r3557
Handle address-only arguments and return values from the caller's end. The callee does not assume ownership of address-only arguments, so don't forward their ManagedValues to the apply. If the return type is address-only, allocate a local temporary, pass the address to the function, then give ownership of the cleanup to a ManagedValue referencing the address.
Swift SVN r3552
Move SILType to its own header, and make it its own container type consisting of a Type with an "isAddress" bit for representing address types. Move the "isAddressOnly" information from SILGen's TypeInfo onto SILType as a second bit, because address-only-ness is extremely useful for verification outside of SILGen. Instead of mangling function types during type lowering, rely on the fact that SILType is no longer a Type to force us to mangle argument and return types when we see them. (We may eventually need SILFunctionType and SILTupleType things to represent lowered SIL function and tuple types containing addresses, but for now we can lower function and tuple components as needed.)
Swift SVN r3551
Tuple values are currently abused by SILGen for handling function arguments, and dealing with indirect tuples will complicate that logic. Punt on classifying tuples as address-only till we can fix up function handling logic.
Swift SVN r3549
Address-only values are already in memory, so when we materialize one, just transfer ownership of the value in the buffer from the ManagedValue rvalue to the Materialize temporary lvalue.
Swift SVN r3548
Use copy_addr to copy argument addresses into local boxes and to store to the return value address when working with address-only types. Add a bit to ManagedValue so that it knows when it's referencing an address-only value (as opposed to just an address) so it can require that forwarded address-only values be forwardInto-ed a memory location.
Swift SVN r3540
Change over SIL Values and Instructions to work in terms of SILTypes, and update SILGen to lower types where needed. Add LValueType logic to SILType lowering to get rid of those annoying lvalue qualifiers so we can ignore RequalifyExprs. Tighten up the XFAILs in the SIL tests and disable the checks that currently crash.
Swift SVN r3538
Add a getLoweredType() method to SILGen's TypeInfo and logic to convert function signatures and address-only types to their SIL-level representations. Drive a (currently weak) type wedge between lowered and unlowered types by making a SILType subclass of CanType. Make SILConstants take on their lowered function types. This breaks a bunch of SIL test cases, which I've temporarily XFAILed until proper address-only type support can propagate through the rest of SILGen.
Swift SVN r3528
Determining constant types requires help from SILGen because of address-only types, and the type of a constant after SILGen should always be readily available from the ConstantRefInst. Initialize SIL Function objects with their lowered type as well so that it's available to IRGen and SIL passes.
Swift SVN r3526
Represent it as an implicit_convert instruction since it has no runtime representation effect. Factor out the common implicit conversion code among the other ImplicitConversionExpr subtypes.
Swift SVN r3510
Proper handling of existentials requires address-only types. For now, we can implement proper initialization of an existential in memory then "load" it as a hack so we can move on with other nodes.
Swift SVN r3509
ProjectExistential derives the value pointer from an existential, and AllocExistential initializes an existential's witness tables and allocates its value. Tweak SILGen's handling of ExistentialMemberRefExprs to emit a project_existential between querying the method and applying it.
Swift SVN r3508
Handle ExistentialMemberRef for methods by emitting ExistentialMethodInst, similar to ArchetypeMemberRef. Properties still need to be implemented.
Swift SVN r3507
