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
Previously we would wait until CSApply, which
would trigger their type-checking in
`coercePatternToType`. This caused a number of
bugs, and hampered solver-based completion, which
does not run CSApply. Instead, form a conjunction
of all the ExprPatterns present, which preserves
some of the previous isolation behavior (though
does not provide complete isolation).
We can then modify `coercePatternToType` to accept
a closure, which allows the solver to take over
rewriting the ExprPatterns it has already solved.
This then sets the stage for the complete removal
of `coercePatternToType`, and doing all pattern
type-checking in the solver.
SE-390 concluded with choosing the keyword discard rather than forget for
the statement that disables the deinit of a noncopyable type. This commit
adds parsing support for `discard self` and adds a deprecation warning for
`_forget self`.
rdar://108859077
Follow-up to https://github.com/apple/swift/pull/65048
`getDesugaredType` unwraps sugar types that appear in sequence,
to remove sugar from nested positions we need to get a canonical type.
Thanks to @slavapestov for pointing it out.
Generic type aliases, unless desugared, could bring unrelated type variables
into the scope i.e. `TypeAlias<$T, $U>.Context` is actually `_Context<$U>`.
These variables could be inferrable only after the the body the closure is
solved. To avoid that, let's adjust `TypeVariableRefFinder` to desugar types
before collecting referenced type variables.
Resolves: rdar://107835060
Delay constraint generation for capture list until body of
the associated closure is resolved. This means that we can
unify capture checking with that of regular pattern bindings
for multi-statement closures.
Currently ExprPatterns are type-checked during
CSApply. As such, they can cause solution
application to fail with a pattern that isn't
well-formed. I'm planning on moving their
type-checking into the solver, but until then,
lets only do limited exhaustiveness checking for
the switch if there was an error.
rdar://105781521
Currently, this is staged in as `_forget`,
as part of SE-390. It can only be used on
`self` for a move-only type within a consuming
method or accessor. There are other rules, see
Sema for the details.
A `forget self` really just consumes self and
performs memberwise destruction of its data.
Thus, the current expansion of this statement
just reuses what we inject into the end of a
deinit.
Parsing of `forget` is "contextual".
By contextual I mean that we do lookahead to
the next token and see if it's identifier-like.
If so, then we parse it as the `forget` statement.
Otherwise, we parse it as though "forget" is an
identifier as part of some expression.
This way, we won't introduce a source break for
people who wrote code that calls a forget
function.
This should make it seamless to change it from
`_forget` to `forget` in the future.
resolves rdar://105795731
Provide ASTWalker with a customization point to specify whether to
check macro arguments (which are type checked but never emitted), the
macro expansion (which is the result of applying the macro and is
actually emitted into the source), or both. Provide answers for the
~115 different ASTWalker visitors throughout the code base.
Fixes rdar://104042945, which concerns checking of effects in
macro arguments---which we shouldn't do.
Since all of the branches of an `if` statement are joined together
and hence produce the same type, that type should be used to
check whether `buildWithAvailability` is required but missing
regardless of availability condition kind.
Resolves: https://github.com/apple/swift/issues/63764
It's possible for out-of-scope type variable to be the type of
declaration if such declaration is recursively referenced in
the body of a closure located in its initializer expression.
In such cases type of the variable declaration cannot be connected
to the closure because its not known in advance (determined by the
initializer itself).
Resolves: https://github.com/apple/swift/issues/63455
Currently we only consider ParamDecls, but isolated
conjunctions can reference external VarDecls too.
This fixes a spurious "cannot reference invalid declaration"
error when the result builder transform is disabled
in the test case rdar104687668.swift. It also fixes
the attached test case, where an if expression
references a pattern var in a for loop.
rdar://105080067
Introduce SingleValueStmtExpr, which allows the
embedding of a statement in an expression context.
This then allows us to parse and type-check `if`
and `switch` statements as expressions, gated
behind the `IfSwitchExpression` experimental
feature for now. In the future,
SingleValueStmtExpr could also be used for e.g
`do` expressions.
For now, only single expression branches are
supported for producing a value from an
`if`/`switch` expression, and each branch is
type-checked independently. A multi-statement
branch may only appear if it ends with a `throw`,
and it may not `break`, `continue`, or `return`.
The placement of `if`/`switch` expressions is also
currently limited by a syntactic use diagnostic.
Currently they're only allowed in bindings,
assignments, throws, and returns. But this could
be lifted in the future if desired.
For a single expression closure, just use the
expression as the body in the case where we're
coercing to Void, as the return is already
implied. This avoids crashing in
`ClosureExpr::getSingleExpressionBody` with a
double braced body.
Surprisingly it seems nothing is currently calling
`ClosureExpr::getSingleExpressionBody` after
type-checking, so no test case, but later commits
in this patch will exercise this case.
