-
Notifications
You must be signed in to change notification settings - Fork 10.5k
SILGen: Port reabstraction thunks to the new function type representation #19384
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
SILGen: Port reabstraction thunks to the new function type representation #19384
Conversation
a8f8430
to
266e962
Compare
I'm going to need this when emitting reabstraction thunks using the new function pointer representation.
Treat the top level of the parameter list specially, instead of looking at FunctionType::getInput(). There are three cases where we don't translate parameters 1-1: - Imploding the parameter list into a single value when reabstracting a function with the opaque abstraction pattern. This will go away once Swift 3 compatibility is fully removed. - Exploding the parameter list from a single value. This is the dual of the above. - Exploding the parameter list for an SE-0110 "tuple splat" conversion. This is the one case that will need to be supported on an on-going basis, but it is not too bad to handle directly.
Now that we handle the top-level parameter list specially, we never end up with non-materializable tuples here, or other odd cases like one-element tuples, so a bunch of complexity can be eliminated.
266e962
to
e7b911e
Compare
@swift-ci Please test |
@swift-ci Please test source compatibility |
fluent failure is the same non-deterministic associated type thing (rdar://44777661). |
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.
Oh man, seeing the parameter-tuple abstraction patterns go away is glorious.
@@ -892,11 +879,102 @@ namespace { | |||
AnyFunctionType::CanParamArrayRef inputSubstTypes, | |||
AbstractionPattern outputOrigFunctionType, | |||
AnyFunctionType::CanParamArrayRef outputSubstTypes) { | |||
// FIXME: Do we ever do opaque-to-opaque reabstractions? | |||
assert(!inputOrigFunctionType.isTypeParameter() || | |||
!outputOrigFunctionType.isTypeParameter()); |
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.
No, we don't.
This was the last place we used AbstractionPattern::getFunctionInputType(), so a lot of old code can be removed now.