Tuple exploding happens during RValue construction, so changed the constructor and addElement() method to take the location parameter. The imploding happens on RValue::forwardAsSingleValue and RValue::getAsSingleValue(). Make sure the right SIL locations are passed to all of these
Also, added some missing locations in pattern matching code.
Swift SVN r7916
Note that this does not actually require the function containing the [auto_closure] parameter to be marked [transparent]. However, if the function is not marked [transparent], then the [transparent] flag on the application of the [auto_closure] will have no effect anyway because the callee of the function will not be visible, so there's no harm in putting the flag on without checking.
Swift SVN r7904
functions should be serialized.
Transparent is added as a 1-bit field. In SILGen, we set SILFunction's
transparent attribute according to the attribute of the ValueDecl.
Swift SVN r7882
MemberRefExpr now uses ConcreteDeclRef to refer to its member, which
includes the substitutions and obviates the need for
GenericMemberRefExpr.
Swift SVN r7842
Switch on address-only unions using the destructive_switch_union_addr instruction. This is safe to do now thanks to r7812: The destructured value will now naturally be cleaned up instead of the invalidated union.
Swift SVN r7821
Auto generated location should not be a separate location kind since
we might have different kinds of auto generated locations (ex: cleanup,
return). Even though the kind info might not be necessary for diagnostics or
debug info, it allows us to better use type system, for example, only pass
CleanupLocation where expected.
Swift SVN r7816
Before, we left the switch subject rvalue to be cleaned up at the close of the switch's scope. This is a bit wasteful because it keeps the rvalue live long after it's actually needed, and destroying the subject potentially requires replicating a bunch of destructuring we already do in the course of the pattern match. This patch changes things so that, just prior to entering a case, we clean up the destructured occurrence vector we have at the point of entering the case, which should be equivalent to but potentially more efficient than destroying the original subject rvalue.
Swift SVN r7814
I've decided to keep only the location of the scope AST node that corresponds to the cleanup. (Currently, there is no user that needs the originator expression, which caused the cleanup. So keeping things simple.)
Added the cleanup location to the Scope and JumpDest classes, which gets assigned on construction of those. The Scope's and JumpDest locations are used when we emit the cleanup instructions.
We now give better location info for 2 existing tests for definitive initialization.
(+ Rather sparse testing of all this.)
Swift SVN r7764
When performing member lookup into an existential that involves the
DynamicLookup protocol, look into all classes and protocols for that
member. References to anything found via this lookup mechanism are
returned as instances of Optional.
This introduces the basic lookup mechanics into the type
checker. There are still numerous issues to work through:
- Subscripting isn't supported yet
- There's no SILGen or IRGen support
- The ASTs probably aren't good enough for the above anyway
- References to generics will be broken
- Ambiguity resolution or non-resolution
Thanks to Jordan for the patch wiring up DynamicLookup.
Swift SVN r7689
We mark the branch instructions leading into single epilog code with ReturnLocation/ImplicitReturnLocation. If SIL Gen simplifies the code and merges the code representing the return into the epilog block, the terminator of the epilog block (the ReturnInst) will have the return location info on it. Otherwise, the ReturnInst has the RegularLocation, which represents the enclosing FunctionExpr or Constructor/Destructor Decls.
(I've discussed dropping the optimization from SILGen, and keeping the epilog code canonical, with Adrian; but he said that there might not be any wins in doing so, so keeping it for now.)
Added AutoGeneratedLocation to represent segments of code generated by SILGen. This will be used for thunks and other auto-generated segments.
Swift SVN r7634
This was not likely an error-free change. Where you see problems
please correct them. This went through a fairly tedious audit
before committing, but comments might have been changed incorrectly,
not changed at all, etc.
Swift SVN r7631
This is was a very mechanical patch where I basically first renamed SILNodes.def
and then just kept fixing things until everything compiled, so even though it is
large patch I feel ok(ish) with committing it.
If anyone has any concerns/etc, please email me and I will revert in 1 second.
Swift SVN r7604
We had a weird (and problematic for me) situation before where
tuple initializations would not recursively finalize their tuple
elements when they were finalized. Making them do so runs afoul
of the poorly named Initialization::getSubInitializations(x,y,z)
method, which had nothing to do with the
Initialization::getSubInitializations() method. Rename the former
to "getSubInitializationsForTuple" to make it more clear what is
going on, and make it handle the finalization of the SingleElement
initialization when it explodes it.
No functionality change, this unblocks some cases definite init was
tripping over.
Swift SVN r7600
Generate union constructors as SIL functions using the new 'union' instruction. Change UnionTypeInfo::emitInjectionFunctionBody into UnionTypeInfo::emitInjection, which emits the union value to an explosion rather than emitting the scalar return directly, and use it to implement IRGen lowering of the 'union' instruction.
This breaks a few serialization tests because of mangler bugs handling generic unions, which I'll fix next.
Swift SVN r7559
This is a baby step toward eliminating GenericParamList from
PolymorphicFunctionType, fixing up the easy callers. No functionality
change.
Swift SVN r7370
Previously, TypeAliasDecl was used for typealiases, generic
parameters, and assocaited types, which is hideous and the source of
much confusion. Factor the latter two out into their own decl nodes,
with a common abstract base for "type parameters", and push these
nodes throughout the frontend.
No real functionality change, but this is a step toward uniquing
polymorphic types, among other things.
Swift SVN r7345
ForStmt::Cond is already a NullablePtr<>. This patch changes
ForStmt::Initializer and ForStmt::Increment to be NullablePtr. Otherwise it
looks like Cond can be null, while Initializer and Increment can not.
Swift SVN r7265
