There are many cases where getBufferForExpr and manageBufferForExpr occur right
next to each other. The closure based API expresses this pattern in a more
convenient manner where the user can express his/her intent with one action
instead of two. In these cases, the split is messy and not necessary.
The only difference is that the copy value API takes a ManagedValue. Hopefully
once we eliminate direct manipulation of SILValue in SILGen, we can get rid of
the emitManagedRetain API in SILGen.
rdar://29791263
This is actually a NFC change since we forward the cleanup in most cases and the
forwarding behavior is tested already by SILGen. But what this /does/ do is
prevent us from creating a ManagedValue that is "owned" but does not have a
cleanup.
rdar://29791263
SubstitutionList is going to be a more compact representation of
a SubstitutionMap, suitable for inline allocation inside another
object.
For now, it's just a typedef for ArrayRef<Substitution>.
This new API creates a new PHI argument in the current insertion block of the
SILBuilder with @owned ownership, creates a new ManagedValue with cleanup and
returns that ManagedValue. This eliminates one case where often times in SILGen
people use SILBuilder APIs on SILGenBuilder and then manage their own ownership
instead of gliding lightly on top of pure ManagedValue APIs.
rdar://29791263
We already always associate a SILGenBuilder with one function, just like
SILBuilder, so there really is no reason not to store the SILGenFunction. The
reason why I want to do so here though is that I want access to the ManagedValue
APIs on SILGenFunction so I can begin to add Ownership endowed entry points on
SILBuilder that traffic only in ManagedValue instead of SILValue.
rdar://29791263
