Even when we’ve already visited the expression for constraint generation (signified by the presence of an UnresolvedMemberChainResultExpr) we should still cache the chain base.
The old method of generating this placeholder expression caused issues when constraints had to be recursively regenerated during solving. Now, we generate UnresolvedMemberChainResultExprs in walkToExprPre, and use ASTWalker::Parent instead of ConstraintSystem::getParentExpr to find the parent of the chain tail.
This also lets us generate the chain constraints as part of the normal ConstraintGenerator visit, rather than as an extra walkToExprPost step.
Instead of creating the type variable for the unresolved member chain at the location of the last member, we now create it at the associated UnresolvedMemberChainResultExpr.
Previously, when the final element of a chain was a ForceValueExpr, the chain result type got caught up in the logic used to allow ForceValueExprs to properly infer lvalue types. By separating the result type variable from the last member of the chain, we make sure to keep that logic focused only on ForceValueExpr.
Introduce a new expression type for representing the result of an unresolved member chain. Use this expression type instead of an implicit ParenExpr for giving unresolved member chain result types representation in the AST during type checking.
In order to give unresolved member chain result types visibility in the AST, we inject an implicit ParenExpr in CSGen that lives only for the duration of type checking, and gets removed during solution application.
Remove the tracking of unresolved base types from the constraint system, and place it entirely within the generation phase. We have other ways of getting at the base types after generation.
If reference collection discovered at least `ErrorExpr` in the body
of a closure, let's fail constraint generation only if it's a
single-statement closure, decision about multi-statement closures
should be delayed until body is opened.
This helps code completion because `ErrorExpr` could belong to
a statement unrelated to a completion, so it wouldn't affect
its correctness in any way.
Fix a regression introduced by moving the type checking of closure
captures into the constraint system. The pattern-type optimization for
initializations was causing inference of a double-optional where there
shouldn't be one, manifesting in a failure involving implicitly
unwrapped optionals and `weak self` captures.
Fixes rdar://problem/67351438.
Closurea can become 'async' in one of two ways:
* They can be explicitly marked 'async' prior to the 'in'
* They can be inferred as 'async' if they include 'await' in the body
Unlike \keypath expressions, only the property components of #keypath
expressions were being resolved, so index wouldn't pick up references for their
qualifying types.
Also fixes a code completion bug where it was reporting members from the Swift
rather than ObjC side of bridged types.
Resolves rdar://problem/61573935
bindSwitchCasePatternVars() was introduced as a simpler way to wire up
the "parent" links for case variables with same-named case variables
from the previous case item, and is used in the function builders code
to handle switch statements. It duplicated some logic from the
statement checker that did the same thing using a more complicated
algorithm.
Switch (ha ha) the logic in the statement checker over to using
bindSwitchCasePatternVars(), fixing a bug involving unresolved
patterns along the way, and remove the old code that incrementally
wired up the parent links. The resulting code is simpler and is
unified across the various code paths.
Unlike \keypath expressions, only the property components of #keypath
expressions were being resolved, so index wouldn't pick up references for their
qualifying types.
Also fixes a code completion bug where it was reporting members from the Swift
rather than ObjC side of bridged types.
Resolves rdar://problem/61573935
Rather than type-checking captures as separate declarations during
pre-check, generate constraints and apply solutions to captures in
the same manner as other pattern bindings within a constraint
system.
Fixes SR-3186 / rdar://problem/64647232.
While generating constraints for `SuperRefExpr` generator has to figure out
a type of superclass associated with a current reference. Doing so might
produce an empty type (aka `Type()`) when resolution fails, so `getSuperType`
needs to check whether type is valid before attempting to wrap it into `MetatypeType`.
Resolves: rdar://problem/50819554
A given instance of an anonymous closure parameter will always have
the same type (or type variable). This wasn't true when the linked
expression analyzer was implemented, but it is guaranteed now.
VarPattern is today used to implement both 'let' and 'var' pattern bindings, so
today is already misleading. The reason why the name Var was chosen was done b/c
it is meant to represent a pattern that performs 'variable binding'. Given that
I am going to add a new 'inout' pattern binding to this, it makes sense to
give it now a better fitting name before I make things more confusing.
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
Extracts the list of magic identifier literal kinds into a separate file and updates a lot of code to use macro metaprogramming instead of naming half a dozen cases manually. This is a complicated change, but it should be NFC.
Avoid solving constraint system if there's only one viable overload.
This should also avoids a crash we are seeing in
'candidates.size() == 1' branch in the constraint system.
rdar://problem/64636688
