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
