Track the implied result exprs in the constraint
system, and allow arbitrary propagation of
implied results down if/switch expression
branches. This is required for allowing implied
results in non-single-expression closures.
Currently we don't insert an intermediate
`SyntacticElement` locator element for the `if`
statement in a SingleValueStmtExpr, which leads
to an assertion failure when attempting to simplify
a following `TernaryBranch` element.
Move the insertion of the `SyntacticElement` locator
element for the statement into the
SingleValueStmtExpr constraint generation function,
and remove it from the statement visitors themselves.
For the other cases, the `SyntacticElement` was
already being inserted for children of a BraceStmt,
so we were actually previously ending up with
duplicated elements in a couple of places.
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.
This wasn't consistently used, and consequently
could result in some expressions getting their
parents invalidated. Instead, replace it with a
query to make sure we don't try and add an
expression we've already computed the parent info
for.
This models the conversion from an uninhabited
value to any type, and allows us to get rid of
a couple of places where we'd attempt to drop
the return statement instead.
Remove this bit from function decls and closures.
Instead, for closures, infer it from the presence
of a single return or single expression AST node
in the body, which ought to be equivalent, and
automatically takes result builders into
consideration. We can also completely drop this
query from AbstractFunctionDecl, replacing it
instead with a bit on ReturnStmt.
Most clients only want to set one of the two
parameters, split it into `setPattern` and
`setInitContext` (the latter of which now
handles calling `setBinding`).
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.
Start classifying all potential throw sites within a constraint
system and associate them with the nearest enclosing catch node. Then,
determine the thrown error type for a given catch node by taking the
union of the thrown errors at each potential throw site. Use this to
compute the error type thrown from the body of a `do..catch` block
within a closure.
This behavior is limited to the upcoming feature `FullTypedThrows`.
Correctly determining the DeclContext needed for an
ExplicitCaughtTypeRequest is tricky for a number of callers, and
mistakes here can easily lead to redundant computation of the caught
type, redundant diagnostics, etc.
Instead, put a `DeclContext` into `DoCatchStmt`, because that's the
only catch node that needs a `DeclContext` but does not have one.
Teach the constraint system to use the same primitives as elsewhere to
determine the type context for a `throw` statement and the caught
error type within a `do..catch` statement. This makes
explicitly-specified `throws` work on `do..catch` that occurs in
closures.
Cleans up some redundant computations for caught error types.
These two requests are effectively doing the same thing to two
different cases within CatchNode. Unify the requests into a single
request, ExplicitCaughtTypeRequest, which operates on a CatchNode.
This also moves the logic for closures with explicitly-specified throws
clauses into the same request, taking it out of the constraint system.
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.
Augment the TypeVarRefCollector such that it
picks up any type variables present in the result
type for a closure DeclContext when visiting a
ReturnStmt. This ensures we correctly handle
if/switch expressions that contain `return`
statements.
rdar://114402042
These allow multi-statement `if`/`switch` expression
branches that can produce a value at the end by
saying `then <expr>`. This is gated behind
`-enable-experimental-feature ThenStatements`
pending evolution discussion.
Fix an issue uncovered by the stress tester where
the brace element skipping logic could still attempt
to skip a single-expression body of an if/switch
expr.
Skip type-checking multi-statement branches if the
completion is in a single-expression branch, and
skip type-checking the expression as a whole if
the completion is in a multi-statement branch.
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 matches what we do in VarRefCollector, and is
needed because we currently delay the pre-checking
of patterns due to the fact that we don't resolve
them until CSGen. We ought to consider changing
this, but until then, adjust the logic here to
ensure we properly connect an ExprPattern that
references an outer var with any type variables
it may involve.
rdar://112264204
Both single- and multi-statement closures now use variable reference
collector to identify variables used in the interpolation body, which
means that it's not longer necessary to connect to the closure explicitly
(if interpolation is contained in one).
Generate a conjunction for each tap expression body as soon as it
gets a contextual type instead of separate post-factum type-checking
via `typeCheckTapBody`.
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.
Apply the same logic that we apply to other
conjunction elements, to make sure that e.g
property wrapper projected values work correctly.
rdar://110649179
This is wrong because there's nowhere to put any
conversion that is introduced, meaning that we'll
likely crash in SILGen. Change the constraint to
equality, which matches what we do outside of the
constraint system.
rdar://107709341
