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
Introduce `ConstraintSystem::recordTypeVariablesAsHoles` as a
standard way to record that unbound type variables found in a
type are holes in the given constraint system.
When matching a result builder in the constraint system, the closure has already been pre-checked so we don’t need to pre-check it again. Also, we can continue type checking even if the closure contained an `ErrorExpr` since result builders are now type checked like regular closures.
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.
This fixes an issue if the range ends with a string literal that contains the IDE inspection target. In that case the end of the range will point to the start of the string literal but the IDE inspection target is inside the string literal and thus after the range’s end.
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.
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.
The impact should be very high because the whole body is skipped
if the builder does not support some of the operations, otherwise
the fix would interfere with result builders that do support
operations but have syntactic issues in the body.
Resolves: rdar://89880662
In cases like:
```
if (...) {
<body>
} else if (...) {
<body>
} else if (...) {
<body>
}
```
Each branch should end with `buildOptional` wrapping `buildEither`
because there is no covering unconditional `else` in the sequence:
```
var $__builder: <<Type>>
if (...) {
$__builder = buildOptional(.some(buildEither(...)))
} else {
if (...) {
$__builder = buildOptional(.some(buildEither(...)))
} else {
if (...) {
$__builder = buildOptional(.some(buildEither(...)))
} else {
$__builder = buildOptional(.none)
}
}
}
```
Resolves: rdar://104345754
Placeholder variable that represents result of `if` should be placed
at the beginning of the statement, same goes for `Optional(.some(...))`
that wraps the expression in "then" branch.
Resolves: https://github.com/apple/swift/issues/62848
Inject `buildBlock` call into `return`, `buildFinalResult`, and
`build{Optional, Either}` to take advantage of contextual information
and maintain compatibility with current inference behavior.
`getValue` -> `value`
`getValueOr` -> `value_or`
`hasValue` -> `has_value`
`map` -> `transform`
The old API will be deprecated in the rebranch.
To avoid merge conflicts, use the new API already in the main branch.
rdar://102362022
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.
Result builders would be able to declare:
- uninitialized variables
- variables with property wrappers (with and without explicit initializer)
- default initializable variables i.e. `var x: Int?`
- computed variables
- `lazy` variables
If `CompletionContextFinder` fails to find a `CompletionNode`, skip
trying to filter and add solutions to the completion callback. This
prevents an assertion/crash in `filterSolutionsForCodeCompletion` which
assumes `CompletionNode` is non-null (either an expression or keypath).
Resolves rdar://99966094.
Replace the use of bool and pointer returns for
`walkToXXXPre`/`walkToXXXPost`, and instead use
explicit actions such as `Action::Continue(E)`,
`Action::SkipChildren(E)`, and `Action::Stop()`.
There are also conditional variants, e.g
`Action::SkipChildrenIf`, `Action::VisitChildrenIf`,
and `Action::StopIf`.
There is still more work that can be done here, in
particular:
- SourceEntityWalker still needs to be migrated.
- Some uses of `return false` in pre-visitation
methods can likely now be replaced by
`Action::Stop`.
- We still use bool and pointer returns internally
within the ASTWalker traversal, which could likely
be improved.
But I'm leaving those as future work for now as
this patch is already large enough.
Introduce the compiler directive `#_hasSymbol` which will be used to detect whether weakly linked symbols are present at runtime. It is intended for use in combination with `@_weakLinked import` or `-weak-link-at-target`.
```
if #_hasSymbol(foo(_:)) {
foo(42)
}
```
Parsing only; SILGen is coming in a later commit.
Resolves rdar://99342017
Fixes a bug in `buildOptional` injection for `if else` branches
without unconditional `else` which leaves type-join with just `.some(...)`
and results in optionality mismatch if `buildOptional` don't not produce
an optional type.
function body, map the result builder type into context.
This was already done for inferred result builder attributes; now,
the constraint system will map the builder type into context for all
result builder attributes applied to computed properties/functions.
If `buildBlock` is also unavailable, or the
builder itself is unavailable, continue to solve
using `buildPartialBlock` to get better
diagnostics.
This behavior technically differs from what is
specified in SE-0348, but only affects the invalid
case where no builder methods are available to use.
In particular, this improves diagnostics for
RegexComponentBuilder when the deployment target
is too low. Previously we would try to solve using
`buildBlock` (as `buildPartialBlock` is unavailable),
but RegexComponentBuilder only defines `buildBlock`
for the empty body case, leading to unhelpful
diagnostics that ultimately preferred not to use
the result builder at all.
rdar://97533700
Previously we would cache the result of the first
query, with any further query of
`ResultBuilder::supports` ignoring the
`checkAvailability` parameter. Separate out the
availability checking such that we compute the
information up front, and adjust the result
depending on `checkAvailability`.
