"Function builders" are being renamed to "result builders". Add the
corresponding `@resultBuilder` attribute, with `@_functionBuilder` as
an alias for it, Update test cases to use @resultBuilder.
Return type in the closure signature is often redundant when expanding
placeholders, because the type of the clossures are usually inferred
from the context (i.e. calling function), users don't need to write the
return type explicitly.
They are not only redundant, but also sometimes harmful when the return
type is a generic parameter or its requirement. Actually, there is no
correct spelling in such cases.
So omit the return type and the parentheses around the parameter clause.
rdar://problem/63607976
Since placeholder expansion works with a single placeholder, which is
somewhat at odds with multiple-trailing closures, we eagerly attempt to
expand all consecutive placeholders of closure type. That is, if the API
has multiple closure parameters at the end, expanding any one of them
will transform all of them to the new syntax.
Example
```
foo(a: <#T##()->()#>, b: <#T##()->()#>)
```
expanding *either* parameter will produce the following:
```
foo {
<#code#>
} b: {
<#code#>
}
```
(caveat: the indentation is not part of placeholder expansion, but it's
added here for clarity)
At least for now we do not attempt to corral an existing closure into
the new syntax, so for
```
foo(a: { bar() }, b: <#T##()->()#>)
```
The exansion will be
```
foo(a: { bar() }) {
<#code#>
}
```
as it was before.
rdar://59688632
Instead of getting all edits up front using the same source code, apply
each replacement before calculating the next. Placeholder expansion is
sensitive the surrounding code, so expanding multiple closures
separately can give different results from doing so in order. To allow
testing that, add a magic placeholder identifier __skip__ to skip
expansion during testing.
This is also required for handling multiple trailing closures.
Update the PlaceholderFinder ASTWalker to walk into the clauses of
IfConfigDecls. It wasn't previously, resulting in any placeholders there not
being expanded.
Also update CallExprFinder (used to determine if expansions should use trailing
closure syntax) to walk into inactive if-config clauses. Previously it only
walked into active regions, so expansions never used trailing closure syntax in
inactive regions.
Resolves rdar://problem/51995648
In addition to brace statements (previously handled), several other
statements allow a trailing closure (return, yield, throw). Also fix the
handling of statements nested within expressions for closures - both
single-expression bodies and brace statements.
This also fixes a particular regression caused by single-expression
function bodies where we would fail to expand to a trailing closure when
a function body only contained a single expression.
rdar://50227500
When expanding placeholders, we analyze the surrounding context of a
placeholder to decide whether to expand the placeholder to a trailing
closure. This analysis assumes CallExpr is the only AST node with argument;
however UnresolvedMemberExpr can have argument as well. This commit
teaches the analysis logic to handle both.
SourceKit invariantly expands the last argument in a function call as trailing closure,
if it is of function type. However, there are situations when inline closures
are preferred; for example, when the last argument is not the only closure in the function
call. This patch modifies SourceKit so that when the argument contains multiple closures,
the last argument is expanded as inline closure.
The code goes into its own sub-tree under 'tools' but tests go under 'test',
so that running 'check-swift' will also run all the SourceKit tests.
SourceKit is disabled on non-darwin platforms.
