If one of the statements in the result builder body fails to
apply solution, let's fail entire rewrite attempt, otherwise
type-checker would end up with AST that has null pointers for
some child nodes.
Resolves: rdar://problem/70256351
It was used for unresolved member and `.dynamicType` references
as well as a couple of other places, but now unresolved member
references no longer need that due to new implicit "chain result"
AST node and other places could use more precise locators
e.g. new `.dynamicType` locator or `sequence element` for `for in`
loops.
We'll need this to get the right 'selfDC' when name lookup
finds a 'self' declaration in a capture list, eg
class C {
func bar() {}
func foo() {
_ = { [self] in bar() }
}
}
The lack of these functions in a function builder is diagnosed in
different places in the type checker. Extend these diagnostics to
provide stubs in the function builder.
Thanks to Suyash for the suggestion!
When performing code completion inside the declaration of a type with
the function builder attribute, also include completions for all of
the possible "build" functions.
Make the lookup of the various `build` functions for function builders
normal, qualified name lookup. This allows (e.g.) the implementation
of many of the 'build' functions to come from a protocol extension,
making function builders more composable. Thank you to @anreitersimon
on the Swift forums for the example!
Add a flag to `ConstraintSystem::preCheckExpression` and subsequently
to `TypeChecker::resolveDeclRefExpr` to indicate whether it's allowed
to replace invalid member refs with `ErrorExpr`.
It is useful for diagnostics and code completion to preserve AST
in it's original state otherwise it's impossible to diagnose errors
post factum or extract `CodeCompletionExpr` when it's a child of an
invalid reference.
This routine can compute the fallthrough destination on its own. When
it does, we start correctly checking @unknown cases in function
builders, so update and expand the test accordingly.
If there are no 'case' statements in the body let's try
to diagnose this situation via limited exhaustiveness check
before failing a builder transform, otherwise type-checker
might end up without any diagnostics which leads to crashes
in SILGen.
Resolves: rdar://problem/65983237
We used to apply builder transforms to regular
functions without using a constraint system,
which is what the assertion is primarily geared
towards. However we now use a constraint system
for such cases, with the lack of a constraint
system only being used to check if we can even
apply the transform in the first place.
The use of "if #available" in function builders can subvert availability
checking if the function builder carries all type information for the
values within the "then" block outside of the "else" block. Tighten up
the model in two ways:
* Check whether the type coming out of an "if #available" references
any declarations that are not available in the outer context, to close
up the model.
* If the function builder provides a buildLimitedAvailability(_:)
operation, call that on the result of the "then" block in an "if
that it cannot leak out of the "if #available"; if it doesn't, the
check above will still fire.
Stage this in with a warning so function builders out there in the wild
can adapt. We'll upgrade the warning to an error later.
Fixes rdar://problem/65021017.
`PreCheckFunctionBuilderRequest` applies `PreCheckExpression` to the
expressions inside the function body. Previously it used to receive only
`AnyFunctionRef` (`FunctionDecl` or `ClosureExpr`) as the parameter.
However, when fast-completion kicks-in, it replaces the body of the
function, then tries to call `PreCheckFunctionBuilderRequest` again, with
the same function decl as before. It used to return cached "Success"
result, but it didn't actually apply `PreCheckExpression`. So any
`UnresolvedDeclRefExpr` remained unresolved.
In this patch, make `PreCheckFunctionBuilderRequest` receive "body" of the
function as well, so it doesn't return the cached result for the *previous*
body.
rdar://problem/65692922
Before 09db2902d2, the function builder
transform used to try to detect when the builder type wasn't fully
resolved. In such a case, rather than fail the solution set as we do
currently, it would construct a null TypeLoc, then stash the type-
variable-laden builder type inside of a TypeExpr and rely on CSGen
to reinterpret that as a request to read the stashed type as it was
constructing the rest of the system. This used to rely on the ability to construct
an implicit TypeExpr node with a null type but now such a thing is
banned by the TypeExpr interface.
Instead, we have to detect this case and construct an *explicit*
TypeExpr node pointing to all the usual fake data. This node's type will
be used to resolve the build* member, but the final applied type of the
node will be the builder type we stashed earlier - hopefully with
outstanding type variables solved.
rdar://65116204
