Previously, the AbstractionPattern that was used for the value
"returned" (i.e. via a completion handler) from ObjC mostly (but not
quite always) was "type".
The generated completion handler correctly (because this is required in
order to call _resumeUnsafeContinuation) reabstracted the block (e.g.
from @convention(block) to @substituted <T> () -> @out T for <()>). The
callee of the ObjC function, however, loaded the function from the block
as if it were not reabstracted (e.g. () -> ()).
On most platforms, that happened to work. On arm64e, that difference in
types caused in a difference in pointer signing, resulting in a failure
at runtime.
rdar://85526879
rdar://85526916
When converting an ObjC method type which is being called as async to a
Swift function type, some of the values passed to the ObjC method's
completion handler are converted to return values of the Swift function.
The flag and error parameters, however, if present, are ignored.
When abstracting the result type for the Swift method, the formal type
of the corresponding parameter in the ObjC method's completion handler
is used. Digging out that parameter entails indexing into the
parameters of the completion handler. Previously, the indexing logic
relied on the error appearing before the flag if both appeared before
the value of interest. Here, the indexing is tweaked to check both
special indices for each possible index until the first that matches
neither is found.
rdar://81625544
In the synthesized completion handler that is passed to ObjC methods
that are called as async, the formal type of each argument is the
corresponding parameter of the formal type of the block. The non-error,
non-index arguments need to be prepared so that they can be used to
fulfill the continuation; the lambda which does that preparation for
each such argument takes the formal type of that argument. As such, the
call to that lambda needs to pass the type of the corresponding
parameter of the formal type of the block to that lambda. Doing so
entails skipping over the error and flag parameters if they appear
before some of the non-error, non-index arguments.
Previously, no parameters were skipped over. Consequently, when an
error or flag argument preceded one of the non-error, non-index
arguments, the wrong formal type was passed to the preparation lambda.
Here, that is fixed by passing the correct index. The to-be-used
indices for the formal block parameters are the same as the to-be-used
indices for the lowered block parameters minus one reflecting the fact
that the lowered block always has an initial block_storage parameter as
the first argument which the formal type never has.
rdar://81617749
