Skip to content

[Take 2] Reimplement function builders as statement transformations #29331

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

Merged

Conversation

DougGregor
Copy link
Member

@DougGregor DougGregor commented Jan 21, 2020

Refactor the implementation of function builders so they maintain the statement structure of the closure/function body to which they are applied. This replaces the previous "fold everything into a single expression" implementation with one that is better in several regards:

  • It matches better with the evolving function builder proposal/pitch document, which describes the transformation as introducing intermediate local variables to capture the results of each buildBlock/buildExpression/buildIf/etc. invocation. The result is easier to reason about.
  • It allows generalization to statement kinds that cannot be expressed in a single expression, e.g., if let, although each of these will require work.
  • It charts a path toward a more usable model for type checking multi-statement closures

This refactoring is a major step toward generalizing function builders (rdar://problem/50426203) and fixes a related issue with delaying constraints for single-expression closures (rdar://problem/58695803).

…ations.

ASTScopes completely skip implicit pattern bindings, so don't mark
generated ones as implicit. Instead, give them suitable source
location information.

Fixes rdar://problem/58710568.
…ariables.

Collect all references to parameters whose types involve type variables,
including in closures that aren’t single-expression. This fixes a type
checker assertion that occurs when the constraint graph can get disconnected
with the combination of delayed constraint generation for single-expression
closures and the use of function builders.

Fixes rdar://problem/58695803.
@DougGregor DougGregor changed the title Generalize functions builders again [Take 2] Reimplement function builders as statement transformations Jan 21, 2020
@DougGregor
Copy link
Member Author

@swift-ci please smoke test

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.

1 participant