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
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
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
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
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
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
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
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
Pass down the AST type from the ArchetypeMemberRefExpr, which has the right locally-bound archetypes, rather than derive the method type from the decl.
Swift SVN r3504
Use ArchetypeMethodInst to implement ArchetypeMemberRefExprs that reference methods. Properties are not yet handled. Fix up ArchetypeInst implementation a bit to substitute the "This" type in the method type and to accept archetype-metatypes in addition to archetype addresses.
Swift SVN r3503
Subscripts are just another kind of property. Refactor some logic from ApplyExpr codegen to visit index arguments consistently with apply arguments. Also move the logic for determining SIL constant types onto SILModule because it's too hairy to calculate on the fly.
Swift SVN r3452
Derives the address of a member from the address of a fragile value type. SIL extract : SIL element_addr :: LLVM extractvalue : LLVM getelementptr. Also add SILVerifier checks for ExtractInst and ElementAddrInst that they deal only in values and addresses, respectively.
Swift SVN r3391
We need something more general than ValueDecl to be able to talk about anonymous functions, curried entry points, etc. as SIL constants. SILConstant is a (ValueDecl | CapturingExpr) union with an additional index for discriminating multiple instances or entry points derived from the same AST entity. Update ConstantInst and SILModule's function table to be keyed by SILConstant rather than ValueDecl.
Swift SVN r3372
If an lvalue DeclRefExpr doesn't have a local VarLocs entry in the current SILGen function, assume it's a global variable and generate a constant_ref to get at its address. Eventually there should be a SILGenModule with which we can check that the global access is valid. Either ConstantRef should be renamed or a new GlobalVarRef instruction should be added as well.
Swift SVN r3319
Remove the AllocTmp instruction and represent MaterializeExpr allocations using 'alloc_var stack'/'dealloc_var stack' instructions. Rename Dealloc to DeallocVar, and add an AllocKind attribute to AllocVar and DeallocVar. Update MaterializeExpr SILGen to generate an AllocVar with a DeallocVar cleanup instead of AllocTmp. Tweak SILPrinter's presentation of AllocVar and DeallocVar to be in line with what SIL.rst claims.
Swift SVN r3311
Add RetainInst, ReleaseInst, DeallocInst for managing object lifetimes, and CopyInst and DestroyInst for indirectly managing resilient types and other non-materializable types.
Swift SVN r3159
