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.
All of the type variables referenced by a type had to be
handled by `inferVariables` otherwise it would to possible
to bring non-representative variable into scope which in
turn later would get simplied into a variable that doesn't
exist in the active scope and solver would crash.
Resolves: rdar://83418797
`transformedBody` is available only if the flag is set, so there
is no reason to double-check it before application, the presence
of the transformed body is evidence enough.
Invalid syntax could introduce type variables into sequence which
have to be brought into scope otherwise solver is going to crash.
Resolves: rdar://100753270
Replace `AnyFunctionRef` as "context" for syntactic element with
a custom `SyntacticElementContext` to support type-checking of
other constructs in the future.
Split out brace element handling for a couple of
walkers into a new function. The diff for this is
best viewed without whitespace changes. This
should be NFC.
