[5.9] GenericSpecializer: fix a crash with -cross-module-optimization #64634
Conversation
|
@swift-ci test |
|
Why is it bad to create a thunk for an external function? The included test case passes for me (without the corresponding fix on main), so I can't tell what the issue is or whether this fixes it. |
If a thunk needs to be generated for a partial_apply specialization, but the specialization doesn't have a body, bail. rdar://107165121
eeckstein
force-pushed
the
fix-specializer-5.9
branch
from
6147f22 to
ab995c9
Compare
|
@swift-ci test |
It accesses the callee's function arguments (= arguments of the entry block) which are not there if it's an external function.
Oops. I forgot to copy the last line from my isolated test file. |
|
@swift-ci test |
|
Fix for the test file on main: #64668 |
| @@ -3119,6 +3119,12 @@ void swift::trySpecializeApplyOfGeneric( | |||
| << SpecializedF->getLoweredFunctionType() << "\n"); | |||
| NewFunctions.push_back(SpecializedF.getFunction()); | |||
| } | |||
| if (replacePartialApplyWithoutReabstraction && | |||
| SpecializedF.getFunction()->isExternalDeclaration()) { | |||
| // Cannot create a tunk without having the body of the function. | |||
There was a problem hiding this comment.
If you create a main PR to fix the "tunk" typo, you could also explain that thunk creation needs to access the callee function's SIL arguments.
If a thunk needs to be generated for a partial_apply specialization, but the specialization doesn't have a body, bail.
rdar://107165121
This is a cherry-pick of #64632