-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[rbi] Fix demangling of sending results. #78612
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -1093,7 +1093,14 @@ class TypeDecoder { | |
flags = flags.withSendable(); | ||
} else if (child->getText() == "@async") { | ||
flags = flags.withAsync(); | ||
} else if (child->getText() == "sending-result") { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. this is part of the code that I added that handles the legacy demangler code. |
||
flags = flags.withSendingResult(); | ||
} | ||
} else if (child->getKind() == NodeKind::ImplSendingResult) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This block is needed of course since we were not handling ImplSendingResult at all. The reason why it being not there was not an issue is b/c we also place a bit on the individual result info... so we got the appropriate bits from there. |
||
// NOTE: This flag needs to be set both at the function level and on | ||
// each of the parameters. The flag on the function just means that | ||
// all parameters are sending (which is always true today). | ||
flags = flags.withSendingResult(); | ||
} else if (child->getKind() == NodeKind::ImplCoroutineKind) { | ||
if (!child->hasText()) | ||
return MAKE_NODE_TYPE_ERROR0(child, "expected text"); | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -677,6 +677,10 @@ Type ASTBuilder::createImplFunctionType( | |
auto type = result.getType()->getCanonicalType(); | ||
auto conv = getResultConvention(result.getConvention()); | ||
auto options = *getResultOptions(result.getOptions()); | ||
// We currently set sending result at the function level, but we set sending | ||
// result on each result. | ||
if (flags.hasSendingResult()) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This ensures that we maintain the invariant that I mentioned above that if the flags have a sending result, we also set the options bit on each SILResultInfo to mark them as sending. |
||
options |= SILResultInfo::IsSending; | ||
funcResults.emplace_back(type, conv, options); | ||
} | ||
|
||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -2301,6 +2301,19 @@ void ASTMangler::appendImplFunctionType(SILFunctionType *fn, | |
OpArgs.push_back('H'); | ||
} | ||
|
||
// Mangle if we have a sending result and we are in a recursive position. | ||
// | ||
// DISCUSSION: We only want sending results to change ABI if it is using in a | ||
// function value passed to a parameter or generic position... but not if it | ||
// is just added to a return type. | ||
// | ||
// E.x.: | ||
// | ||
// func foo() -> sending X // No mangling | ||
// func bar(_ x: () -> sending X) {} // Add to mangling for x | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This comment implies that impl-function-type mangling is ABI, and it should probably be removed There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes. Sorry! I forgot to remove it. |
||
if (isInRecursion && fn->hasSendingResult()) | ||
OpArgs.push_back('T'); | ||
|
||
GenericSignature sig = fn->getSubstGenericSignature(); | ||
|
||
// Mangle the parameters. | ||
|
@@ -2313,10 +2326,6 @@ void ASTMangler::appendImplFunctionType(SILFunctionType *fn, | |
appendType(param.getInterfaceType(), sig, forDecl); | ||
} | ||
|
||
// Mangle if we have a sending result. | ||
if (isInRecursion && fn->hasSendingResult()) | ||
OpArgs.push_back('T'); | ||
|
||
// Mangle the results. | ||
for (auto result : fn->getResults()) { | ||
OpArgs.push_back(getResultConvention(result.getConvention())); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I noticed this when I was preparing the test cases for this PR. For some reason we were generating the thunks I was not expecting (since we were losing the sending result bit) and then due to the adjustFunctionType code generation, we were recovering. I tracked down that this was occurring due to SILGenPoly using this API and found this thinko. It didn't change any actual test output though, so I think we have been getting lucky.