This commit essentially consistes of the following steps:
- Add a new code completion key path component that represents the code completion token inside a key path. Previously, the key path would have an invalid component at the end if it contained a code completion token.
- When type checking the key path, model the code completion token’s result type by a new type variable that is unrelated to the previous components (because the code completion token might resolve to anything).
- Since the code completion token is now properly modelled in the constraint system, we can use the solver based code completion implementation and inspect any solution determined by the constraint solver. The base type for code completion is now the result type of the key path component that preceeds the code completion component.
This resolves bugs where code completion was not working correctly if the key path’s type had a generic base or result type. It’s also nice to have moved another completion type over to the solver-based implementation.
Resolves rdar://78779234 [SR-14685] and rdar://78779335 [SR-14703]
Abstract away the TupleExpr gunk and expose
`getLHS` and `getRHS` accessors. This is in
preparation for completely expunging the use
of TupleExpr as an argument list.
`PreCheckExpression` already skips calls, make sure that invalid subscripts,
dynamic subscript, ObjC literals preserve paren/tuple for an index/argument.
Resolves: rdar://61749633
While 'defer' is implemented as a local function, it doesn't
behave as one. In particular, since SILGen runs it after
destroying all local bindings that appear after the 'defer'
definition, the body of a 'defer' cannot forward reference
captured bindings the way that local functions can.
Note that I had to remove a SILGen test case for an older,
related issue. The new diagnostic in Sema catches these cases
earlier.
Fixes rdar://problem/75088379.
Now that we're checking DiscardAssignmentExprs in PreCheckExpr, we have to be careful to make sure we don't diagnose anything until after SequenceExprs have been folded, since the relevant AssignExprs won't even have a "right hand side" and "left hand side" until after folding.
Move markAcceptableDiscardExprs into PreCheckExpr so that we can perform this analysis before we convert expressions like `_? = <value>` into `_ = <value>` since `_?` is now an expression with meaning, and we only want to perform this transformation when `_?` is on the LHS of an assignment
Unwrap `InOutExpr` from all parens until the outermost paren or a tuple
to correctly diagnose calls like `foo(((&bar)))` or `foo(x: (&bar))`,
and suggest a fix-it with moves `&` outside parens.
Resolves: rdar://problem/71356981
Two fixes here:
- The ASTScopeDeclConsumerForLocalLookup needs to visit auxiliary variables
- preCheckExpression() should call ASTScope::lookupLocalDecls() even when
parser lookup is enabled, since otherwise we won't be able to find
auxiliary decls in the current DeclContext.
Before performing an UnqualifiedLookup with Flags::IncludeOuterResults
turned on, call ASTScope::lookupSingleLocalDecl() to find local
bindings that precede the current source location.
If this fails, we perform an unqualified lookup to try to find
forward references to captures, type members, and top-level
declarations.
