[OpaqueValues] Handle PartialApplyInsts and @out tuples. #61846
Conversation
Previously the API was only on FullApplySite, but it is useful to be able to insert code after a partial_apply as well.
Rather than being able to handle only to FullApplySites, it now handles PartialApplyInsts as well.
Use the CallArgRewriter to rewrite uses by partial_apply insts just as uses by apply insts, etc., are rewritten.
When branching to the exit block, flatten an @out tuple return value into its components, as is done for all other return values. In the exit block, when constructing the @out tuple to return, visit the tuple-type-tree of the return value to reconstruct the nested tuple structure: @out tuple returns are not flattened, unlike regular tuple returns.
|
@swift-ci please test |
|
@swift-ci please test source compatibility |
|
@swift-ci please test source compatibility |
|
The source compat failures are both in the type-checker and occurring with other PR requested runs. Merging. |
| void insertAfterInvocation(function_ref<void(SILBuilder &)> func) const; | ||
|
|
||
| /// Pass a builder with insertion points that are guaranteed to be immediately | ||
| /// after this full apply site has completely finished executing. |
There was a problem hiding this comment.
/// after this full apply site has completely finished executing.
This comment still refers to a full apply site
| case FullApplySiteKind::TryApplyInst: | ||
| case ApplySiteKind::ApplyInst: | ||
| case ApplySiteKind::TryApplyInst: | ||
| case ApplySiteKind::PartialApplyInst: |
There was a problem hiding this comment.
The partial application of a closure is not the same as the invocation. So this should be called insertAfterApplication.
I could imagine a useful utility that inserted code after the actual invocation by finding the uses of non-escaping closures. But that's not what this does.
| static SILValue buildReturnValue(SILGenFunction &SGF, SILLocation loc, | ||
| ArrayRef<SILValue> directResults) { | ||
| if (directResults.size() == 1) | ||
| return directResults[0]; | ||
|
|
||
| auto fnConv = SGF.F.getConventions(); | ||
| if (!fnConv.useLoweredAddresses()) { | ||
| // In opaque-values code, nested @out enums are not flattened. Reconstruct |
There was a problem hiding this comment.
This says "nested @out enums". Is it specific to tuples?
I'm still trying to convince myself that it is sufficient for this buildReturnValue logic to really be tuple specific, and specific to the function convention as opposed to the reabstraction pattern. Why is this only an issue for closures being passed to generic function types?
We should have @jckarter sign off on this approach
There was a problem hiding this comment.
Yes, this is specific to tuples. The flattening only occurs for tuples.
[OpaqueValues] Follow-up to #61846.
AddressLowering handles PartialApplyInsts as it handles other applies.
SILGen handles @out tuples by flattening the values when passed to the epilog block and by reconstructing the tuple in the epilog before it is returned.
Individual commit messages provide additional details.