This is in preparation for removing the +0 self hack.
This commit in more detail does the following:
1. It adds Formal Evaluation Scopes to certain places where the scopes were
missing. Specifically:
a. The SILGenLValue cases are places where we are invoking accessors. In each
one of these cases, we had a formal evaluation scope in the accessor
itself, but we did not have a scope that closed over the base access and
the accessor access. The base access is a formal evaluation in the sense
that just like with inout bases, we must create a new reference to the
base and re-destroy the base in a chain of accesses. This is to ensure
that we do not extend the lifetime of the base inappropriately.
b. The SILGenPoly case is a place where we have never properly placed a
Formal Evaluation Scope and have completely been relying on the +0 self
hack to make sure that archetype callees are properly destroyed
immediately after a +0 call.
2. It changes all of the places in SILGen that emit self to using formal access
cleanups instead of normal cleanups.
rdar://29791263
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
