Preliminary support for function builders #25221
Conversation
rjmccall added the swift evolution pending discussion 
| @swift-ci Please test. |
rjmccall changed the title 
| Build failed |
| Build failed |
| @swift-ci please smoke test |
| @swift-ci build toolchain |
| @swift-ci please smoke test |
| @swift-ci build toolchain |
| Linux Toolchain (Ubuntu 16.04) Install command |
| macOS Toolchain Install command |
rjmccall force-pushed the function-builders branch 2 times, most recently from 04bab9a to a591499 Compare | @swift-ci Please test. |
| @DougGregor Thanks for fixing the build! Unfortunately I didn't notice that you did this until after I clobbered it with my own fix. 😃 |
| Build failed |
| Build failed |
for 'VarDecl' or if we don't know the kind of the decl. Property delegate allows arbitrary type name (with `@propertyDelegate` attr).
Includes code anticipating property delegates in part because it's been largely stolen from Doug's PR for that.
Turn the generic CustomAttrTypeRequest into a helper function and introduce a FunctionBuilderTypeRequest that starts from a ParamDecl. This has better caching characteristics and also means we only need to do a single cache lookup in order to resolve the type in the normal path. It also means we don't need as much parameterization in the cache. In addition, check that the parameter has function type in the request, not just when late-checking the attribute, and add a check that it isn't an autoclosure.
Provide a place where we can capture more information about the parameters from a declaration being called.
When calling a function whose parameter specifies a function builder with a multi-statement closure argument, transform the closure into a single expression via the function builder. Should the result type checker, replace the closure body with the single expression.
If a function builder contains a buildIf function, then "if" statements will be supported by passing an optional of the "then" branch. "if" statements with an "else" statement are unsupported at present.
Use the opened type from the callee declaration to open up references to generic function builders that contain type parameters. This allows general use of generic function builders.
Fixes rdar://problem/50232955.
rdar://problem/50074177
rdar://problem/50074156
rdar://problem/50074156
rdar://problem/50074177
Make sure we don't suggest any builtin attributes, but only custom type names. rdar://problem/50074177
rdar://problem/50074177
Since we short-circuit in the function builder application when we hit something we cannot translate, relying on that visitor to detect 'return' statements (which disable the application) is bogus. Use a separate, earlier visitor to find 'return' statements consistently. Fixes rdar://problem/50266341.
A substantial amount of this patch goes towards trying to get at least minimal diagnostics working, since of course I messed up the rule a few times when implementing this. rdar://50149837
…olving. When we perform constraint generation while solving, capture the type mappings we generate as part of the solver scope and solutions, rolling them back and replaying them as necessary. Otherwise, we’ll end up with uses of stale type variables, expression/parameter/type-loc types set twice, etc. Fixes rdar://problem/50390449 and rdar://problem/50150314.
rdar://50150690
rdar://50561122
Merging partial solutions can end up assigning the same type to a particular typed node (expression, parameter, etc.), which can lead to unbalanced set/clear when exploring the solution space (and later on, crashes). Don't re-insert such information. This is the same approach taken for type variable bindings, but it's all pretty unfortunate: partial solutions should only record information relative to their part of the constraint system, which would save time and memory during solving. Howver, that's too big a change for right now. Fixes rdar://problem/50853028.
The implicit TypeExprs for function builders were getting inconsistently set types, which would sometimes be the metatype and sometimes not be the metatype, leading to a crash in the new test code.
we're not doing this anymore.
rjmccall force-pushed the function-builders branch from 3c41ffe to b4cdbc0 Compare | @swift-ci Please test. |
rjmccall changed the title | Build failed |
| Build failed |
| We are planning to merge this now in order to simplify progressive development on top of it, since (1) the core team is in basic agreement that we should add this feature in some form and (2) it's a rather large patch and requires constant attention to keep valid. We still anticipate significant changes to the design. I'll be making a similar announcement in the pitch thread. |
4 participants
Provide basic support for function builders, which allow the convenient creation of eDSLs for complex lists and hierarchies.
An evolution pitch for this is forthcoming. That pitch proposes a somewhat more general feature than is implemented here; this work reflects what's available in the current Xcode developer preview.