It would be more abstractly correct if this got DI support so
that we destroy the member if the constructor terminates
abnormally, but we can get to that later.
Bridging an async Swift method back to an ObjC completion-handler-based API requires
that the ObjC thunk spawn a task on which to execute the Swift async API and pass
its results back on to the completion handler.
This commit is doing a few things:
1. It is centralizing all decisions about whether an operand's owner instruction
or a value's parent instruction is forwarding in each SILInstruction
itself. This will prevent this information from getting out of sync.
2. This allowed me to hide the low level queries in OwnershipUtils.h that
determined if a SILNodeKind was "forwarding". I tried to minimize the amount of
churn in this PR and thus didn't remove the
is{Owned,Ownership,Guaranteed}Forwarding{Use,Value} checks. Instead I left them
alone but added in asserts to make sure that if the old impl ever returns true,
the neew impl does as well. In a subsequent commit, I am going to remove the old
impl in favor of isa queries.
3. I also in the process discovered that there were some instructions that were
being inconsistently marked as forwarding. All of the asserts in the PR caught
these and I fixed these inconsistencies.
Operationally it just means that in SILGlobalVariable blocks, all operands have
ownership constraint:
{OwnershipKind::Any, UseLifetimeConstraint::NonLifetimeEnding}
and all values yield an ownership kind of: OwnershipKind::None.
We don't introduce a new mangling here.
To distinguish the names of the original asyncHandler function and it's generated "body-function", we just mangle the body-function with an async attribute, i.e. as if it was declared as async.
This change is mostly to pass information to the ASTMangler to mangle a not async function as "async".
In derivatives of loops, no longer allocate boxes for indirect case payloads. Instead, use a custom pullback context in the runtime which contains a bump-pointer allocator.
When a function contains a differentiated loop, the closure context is a `Builtin.NativeObject`, which contains a `swift::AutoDiffLinearMapContext` and a tail-allocated top-level linear map struct (which represents the linear map struct that was previously directly partial-applied into the pullback). In branching trace enums, the payloads of previously indirect cases will be allocated by `swift::AutoDiffLinearMapContext::allocate` and stored as a `Builtin.RawPointer`.
These create*AndFold APIs are actively harmful when used in TypeLowering since:
1. In general they are a problem since it is weird for a builder API to remove
an instruction.
2. These APIs do not take an erase callback that must be used in passes that
need to update state before erasing the instruction.
3. The typelowering APIs that use this are emitDestroyValue/etc which are the
main APIs that we are using to write code that works with OSSA/non-OSSA
SIL. So we are going to use these APIs in many more places, introducing this
bug in many places.
With that in mind, I have been committing small cheap ARC optimizations to
GuaranteedARCOpts (SemanticARCOpts with expensive optimizations turned off) so
that we can eliminate this without massively churning the code. We are at this
stage now, so it makes sense to turn this off.
I think what was happening here was that we were using one of the superclass
classofs and were getting lucky since in the place I was using this I was
guaranteed to have single value instructions and that is what I wrote as my
first case X ).
I also added more robust checks tieing the older isGuaranteed...* APIs to the
ForwardingOperand API. I also eliminated the notion of Branch being an owned
forwarding instruction. We only used this in one place in the compiler (when
finding owned value introducers), yet we treat a phi as an introducer, so we
would never hit a branch in our search since we would stop at the phi argument.
The bigger picture here is that this means that all "forwarding instructions"
either forward ownership for everything or for everything but owned/unowned.
And for those listening in, I did find one instruction that was from an
ownership forwarding subclass but was not marked as forwarding:
DifferentiableFunctionInst. With this change, we can no longer by mistake have
such errors enter the code base.
Interestingly this problem can only occur if one invokes
MarkUninitializedInst::getKind() directly. Once our instruction is just a
SILInstruction, we call the appropriate method so we didn't notice it.
I used Xcode's refactoring functionality to find all of the invocation
locations.
