Instead of using `one-way` constraints, just like in closure contexts
for-in statements should type-check their `where` clauses separately.
This also unifies and simplifies for-in preamble handling in the
solver.
This avoids a crash that could occur when
attempting to query their interface type later,
which could cause us to attempt to type-check
the Decl separately from its enclosing closure.
Eventually we also ought to use this to fill in
ErrorTypes for expressions (since type-checking
ought to only produce typed AST), but I'm leaving
that as future work for now.
rdar://120012473
Unify with `CTP_ReturnStmt`, and have the
SyntacticElementTarget carry the ReturnStmt for
regular type-checking, which we can use to record
implied returns.
Unify the implementation between single-expression
and multi-statement closures. Because we're now
storing a contextual type for single expression
closure returns, update a code completion test to
bring its behavior inline with the multi-statement
case.
Use the PatternBindingInitializer context if we
have one. This also uncovered a parser issue where
we would mistakenly create a
PatternBindingInitializer in top-level code after
parsing the initializers.
Type-checker separates `where` clause from `for-in` statement's pattern/sequence
in closure contexts which works as a natural barrier for inference, but
for-in statements in i.e. function bodies still type-check all of the for-in
statement components together, so we need to make sure that where clause
cannot be used to infer a type of the pattern before its sequence expression.
Resolves: rdar://117220710
Doing so fits better into conjunction model which leads to more
granular control over what variables are brought into scope during
`where` clause expression checking.
These changes also remove "one-way bind" flag from "for-in" statement
target.
Move the contextual type locator onto
ContextualTypeInfo, and consolidate the separate
fields in SyntacticElementTarget into storing a
ContextualTypeInfo. This then lets us plumb down
the locator for the branch contextual type of an
if/switch expression from the initial constraint
generation, rather than introducing it later. This
should be NFC.
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
For an external property wrapper, there may not be
a pattern here. I believe this should only be hit
during `-debug-constraints` or if there's a too
complex error (which I'm not sure is possible to
produce in this case), so no test.
