With multi-statement closure inference enabled "outer candidates"
hack needs to be careful with its use of `isInvalid()` because some
of the declarations lookup finds might be coming from a multi-statement
closure that being type-checked, such declarations have to be avoided
as candidates, otherwise calling `isInvalid` on them results in a circular
type-checking.
Resolves: rdar://85843677
This restores original pre-check behavior and is important for diagnostics
like `'_' can only appear in a pattern or on the left side of an assignment`.
All other declarations encountered in a body of a multi-statement
closure are handled during solution application via calling
`TypeChecker::typeCheckDecl` that would run its own pre-check.
- Explicitly limit favoring logic to only handle
unary args, this seems to have always been the
case, but needs to be handled explicitly now that
argument lists aren't exprs
- Update the ConstraintLocator simplification to
handle argument lists
- Store a mapping of locators to argument lists
in the constraint system
- Abstract more logic into a getArgumentLocator
method which retrieves an argument-to-param locator
from an argument anchor expr
With the removal of TupleExpr and ParenExpr argument
lists, it's no longer sufficient to check whether
a given parent expr has a possible chain sub-expr,
as it might be a child that's unrelated to the chain
under consideration. For example, for a chain that's
an argument to a function call, we don't want to
walk up and consider the call expr to be an extension
of the chain just because it has a function expr.
Tighten up the check by comparing whether the given
sub-expr of a possible chain parent matches the
current expr in the chain.
With the introduction of the ArgumentList type,
argument expressions will be direct decedents of
call expressions, without an intermediate TupleExpr.
As such, we need to tweak isValidTypeExprParent to
consider the child expression such that `T(x)` is
permissible, but `x(T)` is not.
Change isValidTypeExprParent to take a child expr
parameter, and update its use in MiscDiagnostics
and PreCheckExpr. For PreCheckExpr, switch from a
stack to walking the parent directly, as a
stack-based approach would be a bit more fiddly in
this case, and walking the parents shouldn't be
expensive.
This should be NFC, I'm splitting it off from the
ArgumentList refactoring to make the rebasing there
a little more straightforward.
It's been quite a long time since this unused parameter was introduced.
The intent is to produce the module as a root for the search - that is,
computing the set of conformances visible from that module, not the set
of conformances inside of that module. Callers have since been providing
all manner of module-scoped contexts to it.
Let's just get rid of it. When we want to teach protocol conformance
lookup to do this, we can revert this commit as a starting point and try
again.
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.
