Skip to content

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

Conversation

slavapestov
Copy link
Contributor

@slavapestov slavapestov commented Sep 19, 2018

This was the last place we used AbstractionPattern::getFunctionInputType(), so a lot of old code can be removed now.

@slavapestov slavapestov force-pushed the remove-function-input-abstraction-pattern branch 2 times, most recently from a8f8430 to 266e962 Compare September 25, 2018 23:33
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.
@slavapestov slavapestov force-pushed the remove-function-input-abstraction-pattern branch from 266e962 to e7b911e Compare September 26, 2018 06:15
@slavapestov slavapestov changed the title Remove AbstrationPattern::getFunctionInputType() [WIP] SILGen: Port reabstraction thunks to the new function type representation Sep 26, 2018
@slavapestov
Copy link
Contributor Author

@swift-ci Please test

@slavapestov
Copy link
Contributor Author

@swift-ci Please test source compatibility

@slavapestov
Copy link
Contributor Author

fluent failure is the same non-deterministic associated type thing (rdar://44777661).

Copy link
Contributor

@rjmccall rjmccall left a 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());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, we don't.

@slavapestov slavapestov merged commit de697dc into swiftlang:master Sep 26, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants