Preliminary support for function builders #25221
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.
The text was updated successfully, but these errors were encountered:
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.
Make sure we don't suggest any builtin attributes, but only custom type names. 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.
…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.
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.
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.