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
LValue components can't derive their member types from the type decl because a generic type decl has unbound type vars. Get the type for the MemberRef lvalue component from the expr. Add a RequalifyComponent type because we don't fake the right LValueType qualifiers anymore.
Swift SVN r3500
When deriving the specialized subscript accessor type from a generic subscript, we can't get the index type from the decl, because its type variables will be unbound. Get the type from the index expression node instead.
Swift SVN r3499
According to John, the AST representation of type variable values, which currently appear as GenericMemberRefExprs on the generic metatype, might be wrong. For now, I'll handle these by emitting metatype instructions on the type variable type, which should work because the method already has a local type variable representing the same variable.
Swift SVN r3497
Add instructions to represent type coercion and downcast conversion operations. Factor out a common ConversionInst base class for Convert and these instructions, and rename ConvertInst to ImplicitConvertInst to distinguish it from these new explicit conversion instructions.
Swift SVN r3490
Have SpecializeInst own its Substitution array so that a SpecializeInst can be instantiated independently of a backing SpecializeExpr in the AST.
Swift SVN r3483
Add visitors for GenericMemberRefExpr so that accessors to generic physical members with monomorphic types work. Access to members with generic types still requires proper archetype support. Access to logical properties currently breaks because of a bug in the generation of property method types.
Swift SVN r3480
If a ScalarToTupleExpr is building a multiple-element tuple with default arguments, it's not valid for an apply expression to peek through it to directly generate its argument. Check that a ScalarToTupleExpr result actually has a single element before applying the special case.
Swift SVN r3470
Properties don't need to do the load/retain/store/release dance of physical elements; the setter handles all of that. Rename emitStoreToLValue to emitAssignToLValue, and push the physical reassignment logic into emitAssignToLValue. Dump the old emitAssign since emitAssignToLValue now does everything it used to do. Add a FullExpr scope to the left-hand side of AssignStmts so their temporaries have better-fitting lifetimes.
Swift SVN r3461
In the SILGenLValue visitor, stop when we see a subexpression that has a reference type and use the result of that expression to root the lvalue expression. This allows rvalue reference type expressions like `foo().bar = bas` to work.
Swift SVN r3460
Split CleanupMaterialize into CleanupMaterializeAlloc and CleanupMaterializeValue. Have emitMaterialize, emitGetProperty, and other methods that create materialize buffers return a new Materialize type, which has a consume() method to disable the CleanupMaterializeValue cleanup, load the value, and return it as a ManagedValue for the caller to consume.
Swift SVN r3458
emitReleaseRValue is smart enough to do nothing with trivial types, but a useless load instruction was still being generated for cleaning up materializes. Don't do that.
Swift SVN r3455
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
Generalize a bunch of code that assumed address-of-value-type for the "this" side of properties to accept reftypes as well. Use RefElementAddrInst to extract physical elements of reference types. Fix an off-by-one in the writeback logic in emitStoreToLValue so that writeback chains properly terminate at the deepest value type component below a reference type component.
Swift SVN r3445
Visit ApplyExpr arguments with SILGenLValue. If the resulting path is purely physical, pass it through to the function. If the path has logical components, materialize the logical property and write it back after applying the function.
Swift SVN r3441
SILGenFunction::emitConstantRef was returning a retained reference to local closures, but SILGenLValue saves off the reference and retains it as needed, leading to an extra retain that was never cleaned up. Add a SILGenFunction::emitUnmanagedConstantRef that returns a local or global constant value without retaining a local constant.
Swift SVN r3439
Steal the 'LValue' type from irgen, which describes a logical lvalue as a path through physical and logical accessor expressions, such as member ref, tuple element, and subscript operations. Implement a SILGenLValue visitor that builds logical lvalues for lvalue contexts. Implement assignment using SILGenLValue to visit the left-hand side of assignment statements. Still to be implemented: subscript expressions and byref function arguments.
Swift SVN r3437
Build closures for local getter and setter decls, and load the get closure when the property is referenced in a normal expression context.
Swift SVN r3417
- Steal some bits from SILConstant::id to reference getter and setter definitions, and normalize SILConstant references to property FuncDecls to be SILConstant references to the ValueDecl getter/setter instead.
- In normal expression context, handle getting properties by calling the getter and materializing the return value. Setting lvalues is not implemented yet; that will require borrowing the LValue and GenLValue machinery from irgen to construct logical lvalue paths in assignment and byref contexts.
Swift SVN r3414
Have TypeConverter generate a field-to-index mapping for physical fields of loadable structs.
Use the resulting TypeInfo mapping to generate element_addrs for physical MemberRefExprs, borrowing the logic from TupleElementExpr.
Swift SVN r3406
The type of an Extract from the right-hand side is an rvalue type, not the lvalue type of the corresponding tuple assignment destination.
Swift SVN r3394
If the operand of a TupleElementExpr is an lvalue, derive the address of the element from the operand rather than try to extract a value from it as the code was doing before.
Swift SVN r3392
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
Instead of considering `constant_ref @var` to give the address of `var` directly, consider it to be a `() -> [byref] T` function that returns the address, presumably after running the initializer for the global if necessary. Generate a DeclRef to a global var as a constant_ref to get the function followed by an apply to get the address. Actually generating the global accessor is still to be implemented.
Swift SVN r3389
Change the signature of emitFunction to take just a decl (and leave it up to the implementation to create the SILConstant) because emitFunction may produce functions for multiple SILConstants from a single FuncExpr.
Swift SVN r3388
